Sharks in the Moat

by Phil Martin

  When All Else Fails…

  Because of the various defenses we have covered, a relatively small number of defenders could hold a castle for a long time against a huge invading army. As a result, the best strategy after all other attacks failed was often one of patience on the part of the attacking force by holding a siege. This approach required the attackers to cut off from the castle any supplies or reinforcements and simply wait until the castle defenders gave up. In order for the defenders to win at this game, it was crucial for the castle occupants to have access to some type of resupply route, often provided by a watergate, or a gate in the wall that opened directly to a body of water that friendly ships could visit.

  As an attacking force advanced, people living around a castle would usually run inside of the gates before they were shut, hoping that the castle could successfully hold off the invading army. If access to resupplies was not possible, the castle’s defenders were faced with the problem of too many mouths needing food who were not contributing to the defense of the castle. When a siege set in, the defenders would often send the extra mouths to the outside force, hoping they would let them pass through unharmed. Given that these ‘extra’ mouths were the sick, elderly, women and children, they were usually allowed to leave unharmed.

  These days an attacker will not simply disable a site and then wait for us to close up shop and go home. It is far too easy for us to spin up another copy of the capability somewhere else and keep doing business. However, the siege mentality does live on but in a much shorter timeframe – a hacker will try and disable a site or service by denying the use of the resource to legitimate users. This approach is called a denial of service attack, or DoS attack, and compromises the availability of a site or service. If availability is taken away long enough, the owner will experience a decrease in revenue, and in some extreme cases go out of business because users no longer trust the site to remain up when needed. If designed correctly with load balancing and failover capabilities, though, a site can withstand a DoS attack until the attackers give up and move on. This normally takes place within a few hours instead of a few months as was common with castle warfare. However, some DoS attacks truly take on the scope of a good old castle siege and can last for months. For example, the Operation Ababil DoS attack in late 2012 focused on banking websites, keeping them on the run for almost 6 months before the attackers gave up.

  When undergoing a siege, the surrender of a castle might come as a result of starvation, thirst, sickness or simply good old despair. If the attacking forces promised that the defenders could pass through their lines unharmed, the offer was often taken in the waning days of the siege. Of course, for this to work, the attackers would have to have a good reputation for upholding their promises. In medieval times, honor was a closely guarded commodity, and if a promise was made it was expected to be kept, regardless of how each side felt about the other.

  You might think this activity has no modern corollary, but you would be very wrong. Ransomware is a type of siege attack in which valuable digital files are encrypted and held hostage until the owning company pays a ransom for their release. In 1999 this might have sounded ludicrous, but as the first two decades of the 21st century have shown, the attacks are something to be taken dead seriously given our reliance on digital resources. If not released, the capture of files can easily send a company into bankruptcy due either to decreased revenue or lost trust from customers. This blackmail scheme also aligns with medieval siege tactics in the concept of honor. While I would hardly ascribe the attribute of ‘honor’ to hackers, the ransomware scheme will only work if companies trust that once the ransom is paid, the hacker will send them the correct decryption key to regain access to their own files. This is seldom the case, as some studies have found that while 45% of company’s targeted by ransomware paid the ransom, only 26% actually received the decryption key. That means that you can expect about a 1 in 4 chance that paying the ransom will actually get your files back. Ransomware hackers are a victim of their own greed and lack of honor. Big surprise there, no?

  Chapter 6: Types of Security Controls

  At this point, we have pretty much covered the entire gamut of castle warfare. Interestingly, we have also covered at a high level the cornerstones of creating secure software. But before we leave this section, I want to go over the various types of security controls we will encounter throughout the rest of the book. By doing so, we can connect each type to the related castle capability that addresses the same issue, but in a bygone era. This will greatly help you to understand the various types of controls and their purposes.

  There are six different types of security controls as shown in Figure 29 – deterrent, preventative, detective, compensating, corrective and recovery.

  Figure 29: The Six Types of Security Controls

  Deterrent Controls

  A deterrent control is designed to convince a potential attacker to give up before they even start. If you have seen a ‘This property protected by Gizmo Security’ sign in the front window of someone’s house, then you have witnessed a deterrent control. In terms of castle defense, deterrent controls would include visible guards on top of walls and at gateways, concentric walls that were visible from outside of the castle, and towers from which suspicious activity could be observed. The more imposing a castle was, the less likely it would be attacked.

  In terms of network and system security, deterrent controls include logon banners that inform users that their actions are being watched, video surveillance cameras at entry and exit points, and visible security personnel. Some security controls can be more than one type. For example, activity logs, while normally considered to be a detective control, can act as a deterrent if their existence is widely known.

  Preventative Controls

  While a deterrent control dissuades an attacker before he even decides to act, a preventative control is the reason he will have a hard time breaking through to the keep. Concentric walls must be breached, gateways overrun, and soldiers taken out. In terms of modern security, preventative controls include firewalls, concentric subnets, authentication checks, and physical measures such as locked doors and security guards. Note that security guards were listed as both a deterrent and preventative control – if an attacker sees a security guard they are likely to be deterred and give up, but if they do not a security guard can also prevent them from gaining access.

  Detective Controls

  A detective control uncovers fraud or discovers evidence of an attack, whether it has already happened or is in the process of being carried out. Castle dwellers would monitor activities going on outside of the castle walls from turrets and would listen intently to discover signs of digging under a wall. Gateway soldiers would stop visitors and inquire what business they had inside of the castle. In our networks we often used IDS devices to watch traffic in real time, and periodically review log files to uncover past attempts to penetrate defenses. In high security installations, security guards watch as employees enter and exit to see if there is some type of subterfuge going on.

  Compensating Controls

  A compensating control is designed to make up for a weakness in another control. As an example, castle walls were designed to withstand a direct assault by catapults but were susceptible to undermining. As a compensating control for this type of weakness, bastions were built on top of walls that reached out into the courtyard, enabling soldiers to fight off attackers who tried to dig underneath a wall in an attempt to bring it down. Gateways were initially a major weak point until barbicans and portcullis gates were added to compensate for this liability. In the same manner, we modern cyber soldiers add proxy servers to compensate for traffic that gets past a firewall and encrypt internal traffic so that if someone breaches our physical security and plugs a laptop into the internal network, they cannot sniff passing packets.

  Corrective Controls

  There is not a question of if we will experience a security breach, it is simply a question of when.
And when it happens, we must be ready to get back to operational strength as soon as possible. A corrective control is designed to do just that – it repairs the immediate damage until we are at an operational state once again. There are stories recorded of a castle experiencing significant damage to a wall, and the attacker decided to wait until morning to take advantage of the opening. Unfortunately, during the night the defenders managed to scrape together enough stone and timber from other areas of the castle to do a quick repair job so that the moment was lost. The wall was not permanently repaired but was reinforced enough so that it continued to hold. The repair was a corrective activity.

  In modern terms, a corrective control restores a system to an operational state, even if it is not sustainable for the long-term. For example, if a hacker takes down a crucial system by destroying data, a corrective control would restore the system from a backup so that it continues to function.

  Recovery Controls

  Whereas a corrective control temporarily restores operations, a recovery control ensures that a long-term restoration is applied and addresses the reason that a failure was encountered to begin with. In castle terms, a recovery control would remove the temporary wall fix and replace it with a proper stone and lime mortar mix. A key component in modern recovery controls is to establish root cause of the failure and to ‘fix it’. For example, after an XSS injection attack, we correct it by removing the offending database record containing the malicious script, and then recover by executing an immediate backup procedure and removing the weakness by which the script was injected into the database.

  We’re now finished with exploring how castle warfare aligns with modern information security issues. From this point forward, we’re going to remain in the 21st century while discussing how to implement the various tactics and principles that we have already established. Section 2 will begin with basic security concepts, after which we will dive right into the 12 different roles that deal with secure software. If you find that you are struggling with a concept we have already covered, come visit this section again if you need.

  Section 2: Core Security Concepts

  In this next section, we are going to explore some fundamental topics that you will need to firmly understand. Every subsequent section will build on this one, so don’t skip it!

  Chapter 7: Quality Attributes

  In the software world it is common for people to use various terms to refer to the same concept. In this book we will constantly refer to various attributes that measure quality, so we’re going to set the stage and define a few terms that will keep popping up.

  First of all, quality can be defined as:

  …the degree of excellence as measured against an external standard.

  Of course, without an external standard, it’s going to be really tough to figure out if our software has achieved quality or not. If you do a Google search on ‘quality attributes’ you will encounter a ton of valid results, because everyone and their pet roach seems to have an opinion on the matter. As maligned as Microsoft often seems to be, they have some really smart folks working there and so we are going to use their measuring stick when it comes to quality. They have defined twelve different quality attributes:

  Agility

  The ability of a system to both be flexible and undergo change rapidly.

  Flexibility

  The ease with which a system or component can be modified for use in applications or environments, other than those for which it was specifically designed.

  Interoperability

  The ability of two or more systems or components to exchange information and use the information that has been exchanged.

  Maintainability

  The aptitude of a system to undergo repair and evolution.

  Performance

  The responsiveness of the system.

  Reliability

  The ability of the system to keep operating over time.

  Reusability

  The degree to which a software module or other work product can be used in more than one computer program or software system.

  Scalability

  The ability to maintain or improve performance while system demand increases.

  Supportability

  The ease with which a software system can be operationally maintained.

  Testability

  The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

  Usability

  The measure of a user's ability to utilize a system effectively.

  If you are counting, we just described eleven of the twelve. The last one is especially relevant to this book because it describes security:

  Security

  A measure of the system's ability to resist unauthorized attempts at usage and denial of service, while still providing its services to legitimate users.

  This definition is good at a high level but is woefully lacking in detail and is a little deceptive in its simplicity. In fact, as we work through this book you will continuously encounter all other

  eleven attributes being referenced because security interacts with all of them at some point or the other.

  For example, when discussing integrity – a core security concept - we will be talking about how it increases reliability and scalability. If you will spend a few moments comprehending these twelve attributes now, it will help you make sense of the remaining content in this book.

  Chapter 8: Holistic Security

  Many organizations think that by installing a firewall and creating a demilitarized zone (DMZ) they have established a safe security stance. Unfortunately, the reality is that all the greatest and latest network and perimeter devices in the world will not slow down a persistent hacker if the software is not addressed as well.

  Figure 30: Holistic Security

  This is not to say that network devices are of no value, because they most certainly are. But by themselves they are ill-equipped to handle the wide range of attacks you can expect from a modern hacker. If we dissect the average infrastructure, you will find that there are three tiers that need to be protected – network, host, and the application. Figure 30 illustrates the three different tiers.

  At the network layer we find firewalls, switches, intrusion detection systems, and intrusion prevention systems. These devices allow us to block ports and filter suspicious-looking packets before they enter our network.

  Within the network we find host computers that are almost always running some flavor of Linux or Windows. At this level we need to worry about hardening the operating system and turning a risky server into a bastion host, or a server that has been explicitly hardened against attacks. Activities here include making sure OS patches are properly applied, ensuring proper authorization rules are followed, logging activity and providing fail-over capabilities such as load balancing.

  And then we finally arrive at the level at which this book has been largely designed to address – the software application itself. If an attacker makes it this far – and they often do – then our precious data and servers are history if proper security has not been applied. When we look at all three levels – network, host and application – we are taking a holistic security approach.

  As an example, think about a SQL injection vulnerability. The malicious command will usually arrive over an HTTP port 80 packet, meaning it will fly right past our firewalls and IDS/IPS devices. The host, or web server, will be ill-equipped to recognize such a danger as it does not understand what the application does – it simply hosts the environment on top of which the application runs. Therefore, if the application has not been constructed in such a way as to recognize or defeat a SQL injection attack, we our simply vulnerable and will eventually pay the price.

  Nothing we have discussed so far should be shocking or new to you. Everyone understands the issue, and the solutions are many. Yet, story after story from the news feed details yet anot
her data breach, and they never seem to slow down. What is going on? Why are companies not acting to prevent such incidents from happening? You might find it interesting to know that it boils down to three simple reasons that cover 95% of all exploited vulnerabilities:

  1) The Iron Triangle

  2) Security is an afterthought

  3) Usability trumps security

  Let’s examine each of those and discover why they are such hard things to overcome.

  If you have ever been part of planning, managing or implementing software, then you know about the Iron Triangle – at least in concept. Just imagine a triangle with each vertex representing one constraint that holds back what a development team can deliver. The three vertices are scope, budget and schedule as shown in Figure 31. Scope represents the feature set we want to deliver. Budget represents the number of people who can work on delivering the scope. Schedule dictates how long we have to deliver scope with the specified number of people. The reality is that we will never be able to deliver everything we would like to, and so one of the three vertices must give ground. Budget will need to be increased, schedule will need to extend longer, or scope will need to be reduced. Since a company is seldom willing to increase budget or wait longer for the deliverable, scope will usually suffer. As security features are most often seen as optional, they are the first scope item to fall victim, and therefore are seldom incorporated into the project’s deliverables.