Posted by Synopsys Editorial Team on February 5, 2015
Software developers must build security in from the beginning. It’s the only way to ensure security across the SDLC and minimize the need for “tower defense.”
Too many firms treat software security as a “tower defense” game. When they lose to the attackers, they try to figure out how those attackers “got in.” (To do this, they often hire a firm like Mandiant.) And then they try to build their IT “walls” better. It is tempting to let the bad guy throw rocks at that tower all day long. Then, when the attacker “wins,” we simply redirect some resources to building the walls a bit higher and better. And then we go back to letting attackers throw rocks again.
If we take the Wikipedia article on tower defense games and look at the description, it becomes eerily prescient with respect to some firms’ security posture. A few choice word replacements make this suddenly sound exactly like what’s happening.
Tower defense games Information security systems are characterised by the positioning of static units security controls by the player information security department to defend against mobile enemy units malicious attackers who are trying to get from a start point “outside the network” to an end point “inside the network”. There is a set number of enemy units well-known attack patterns (or ‘damage’ vulnerabilities the player can take from units reaching the end point) who that can reach the end point valuable data before the level it is lost. Some games firms use a static route threat model that the enemy units follow around which the player places their towers security controls, while others favour a free-form environment use architectural risk analysis that allows the user to define the path the enemy units attacks take. Some games firms use a mixture of both. Most games vendors allow the upgrading of the player’s sell different kinds of towers.
Often an essential strategy is
“mazing”defense in depth, which is the tactic of creating a long, winding path of towers security controls to lengthen the distance the enemies must traverse to get past the defense. Sometimes a “ juggling honeypot” is possible by alternating between barricading an exit on one side and then the other side to cause the enemies to path back and forth attack decoy systems safely until they are defeated detected. Some games vendors also allow players firms to modify the attack strategy used by hire towers staff by the hour to be able to defend for an even more reasonable price.
The degree of the
player’s firm’s control (or lack thereof) in such games attacks also varies from games attacks where the player firm actively manages security controls a unit within the game world, to games where the player firm has no direct security controls units at all.
It is a common theme in
tower defense games software security to have air units penetration tests which do not pass through the layout of the maze, but rather fly over test the towers security controls directly to at the end destination.
tower defense games firms or custom maps also require the player to send out enemies attacks to their opponents’ game boards legal entities respectively their controlled areas at a common game board. Such games activities are also known as tower wars games cyberwar.
Software security is not a tower defense game. Firms cannot sit back, let the attacker attack, and then deploy clean-up and forensic resources after the fact. Nor can they just tick the compliance boxes. Attackers don’t care about PCI DSS, HIPAA, or any other compliance standard. In fact, organizations only doing compliance activities, and nothing else, give attackers insight into what the existing security controls are and where to target their attacks. Building software securely from the beginning ensures security across the life cycle of the software. And that’s the best way to minimize the amount of tower defense a firm has to play.
Get the latest Software Integrity news, thought leadership, and more.