Security is like dentistry. You go to the dentist twice a year for reviews and advanced questions, but you don’t go to the dentist to brush your teeth. The security team should function like the dentist: regular checkups and expert issues.
—Robert Garigue, IT Security thought leader, former CISO of Bell Canada & Bank of Montreal
Controls are what you use to reduce risk. Controls can reduce likelihood or impact, and if you’re lucky, they can reduce both. The selection and arrangement of controls is an important step in the IT security program. This chapter explains how to design controls.
A Control Not Used Is a Control Wasted
During the financial crisis of 2008, it was a terrible time to sell a house, but a great time to buy one. My wife and I had just fallen in love with a gorgeous brick Tudor with amazing hardwood floors and a huge finished basement. It was the house of our dreams and super cheap because the sellers were mired in tax court and bankruptcy. The IRS was on the verge of seizing the property, but if we purchased immediately, we could get it. Unfortunately, my credit union wouldn’t underwrite a loan to a property buried in this risky mess. We ended up at a large bank capable of handling the more sophisticated risk. Our loan officer was set up in a small office in a strip mall; his bank recently shotgun-married to a large national bank due to failing assets. He sat at his desk, grumbling and tsk-ing as his hands slapped against the keys of a bulky black laptop with the new bank’s logo stenciled across the case. “I’m sorry. This new system just won’t let me enter your loan information!”
He shook his head, turned around, and reached into his desk drawer. With a smile, he pulled out a second laptop. This one was brand-new and still adorned in advertising stickers from the store. He stacked the new laptop right on top of the other one. It fired it up with a chirp and he began keying in my personal financial details. I raised an eyebrow and opened my mouth, but he silenced me with an upheld hand.
“Oh, the laptop the new bank gave me is so locked down, I can’t do anything. Don’t worry, with this one, I can get your loan done and approved in a few minutes.” I clenched fists under the table. As a security professional, I was horrified that my financial information was being input into this potentially virus-riddled piece of plastic from a CompUSA fire sale. But we wanted this house and this loan was our only shot at getting it. I ground my molars together and gave him a tight-lipped smile as he completed my application.
Here I faced the adage that I had always been warned about: If the controls are too unwieldy, the users will work around them, usually in a more insecure manner than you can imagine. No doubt the gigantic bank was totally unaware that this was going on, especially in that first year of the too-big-to-fail-driven hasty mergers and turnovers.
We are faced with compromises like this from time to time. However, as security professionals, we can do better at control design so people don’t have to take risks just to get things done.
What Is a Control?
We’ve already talked about controls as the tools that you use to reduce risk. Now we’re going to dive deeper into how controls should be selected and used in conjunction to support control objectives. Most technical professionals are already familiar with controls. In fact, control installation and maintenance make up a lot of the day-to-day work of IT security. Because of this overhead, the best controls are fire and forget. Unfortunately, few of them are. But since they are such a heavy burden, it’s worth talking about designing them so that they’re easier to live with. Consider this a metachapter on controls before we get into the specific controls in upcoming chapters.
What Is a Good Control?
A good control has many facets, but the primary function is to adequately reduce a known risk. Your goal is to design controls that meet your compliance requirements as well as a reasonable standard of care. What does this mean? In 1932, there was a landmark legal case involving tugboats towing barges. An unexpected storm hit the boats, and the barges broke free and sank. There were lawsuits, and in the end, the tug operators were found to be negligent for failing to equip their boats with radios (a new technology at the time). The tug operators claimed that radios were so new that no other tug operations in the region were using them. They were still found negligent by Judge Learned Hand, who stated, “There are precautions so imperative that even their universal disregard will not excuse their omission.”1
This concept is relevant to your choices and designs of controls in protecting your organization. You should consider your compliance requirements, especially the ones calling out specific controls, as the minimum standard of care in your design. Furthermore, remember the Mendoza Line for Security: your network must be able to at least resist the attacks of commonly available point-and-click hacking tools. These kinds of basic security controls are what you need to use so you don’t look negligent.
Proportionate to Risk
Control strength should be matched to risk . The obvious best thing to do is build your strongest set of controls for your largest risks. Breaking this down a bit further, when the risk’s impact is high and the likelihood is high, then most of your control work goes into mitigating that risk.
What about when the impact is low, but the likelihood is high? These are the predictable, everyday risks, like spam, non-directed malware, or equipment failure. They’re the background radiation of the Internet: you know they’re going to happen and cause a minor problem. They should be managed like chronic problems, with basic preventative controls. Since they are so common, it’s likely that through sheer multitude of occurrence, a few events are going to get through your controls. In these cases, you should also have a few responsive controls to build resilience to the potential impacts.
Risks where the impact is high, but the likelihood is low are interesting risks to manage. Think of rare occurrences that can be devastating, like malicious insiders or building fires. Often preventive controls for these kinds of risks are expensive or cumbersome. The risk stance should be one of precautionary vigilance, with detective controls set up to look for leading indicators of this risk coming to culmination. This could be as simple as audit logging on insider action with oversight by the security department. You may not prevent the risk from occurring, but you could catch it early enough in the act to mitigate severe damage. Restorative controls can also be set in place to help reduce the impact in the rare event something occurs. Fortunately, many of the restorative controls can be used to resolve many kinds of impacts, not just the ones associated with these risks; for example, failover facilities in case of building fires.
In some cases, risk cannot be feasibly controlled. Consider Courtney’s second law,2 which states: “Never spend more money eliminating a security exposure than tolerating it will cost you.” Courtney’s law also has two corollaries : “Perfect security has infinite cost,” and “There is no such thing as zero risk.”
Standardized and Measured
Good controls are standardized across the organization, with a centralized management hub. This doesn’t mean that you have a single console at headquarters that controls all of your firewalls (although you can if you want). It speaks more to having standards and procedures for controls so that they are implemented in a repeatable and measurable manner.
Good controls are designed so that their functions can be verified and measured. Remember the old management adage: If it moves, then graph it. All controls should have some kind of reporting mechanism, regardless of whether they are technical controls. The easiest-to-monitor controls are designed to send feedback about their functionality directly and quickly. If the control can’t do the reporting, then a verification procedure should be built into the control operation. For example, consider a detective control of video camera recording the entrances and exits into a secure area. Some camera system can e-mail alerts when they detect motion in their area. If your system does not have this kind of feedback on functionality, then you could add a periodic (weekly, monthly?) verification procedure to review video logs to ensure that the system is working. The effectiveness of controls, especially after being deployed in your environment, is examined in detail in Chapter 22.
Documented
Related to standardization and measurement, is control documentation. Auditors will not consider a control secure if the design is not clearly expressed. This documentation would definitely include the policies, standards, and procedures associated with the control. It also can include flow charts, network diagrams, and narratives that spell out how the control functions and what it should accomplish. For SSAE 16 audits, these control descriptions are a mandatory part of the audit report, going into section 3 of the report. All controls should be documented in some way, not only for auditors, but also for your own organizational usage. Having documentation around controls is valuable for internal management and operational training.
Control Lists
For specific control ideas, you should definitely be looking at the compliance control lists within ISO27002:2013 and PCI DSS. If you are going to be audited against these standards, you will need to implement every control that applies. In the case of PCI DSS, every control in the standard does apply. In addition to the large myriad of technical controls for sale by IT security vendors, there are also other control lists available by standards bodies and organizations . Here are some:
NIST SP 800-171
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf
Cloud Security Alliance Cloud Controls Matrix
https://cloudsecurityalliance.org/group/cloud-controls-matrix/
CIS Critical Security Controls
Australian Signals Directorate Top Mitigations
http://www.asd.gov.au/infosec/top-mitigations/mitigations-2014-table.htm
Controls in Combination
You’ve already read about preventative, detective, and corrective controls, as well as administrative, physical, and technical controls. That’s nine different ways (in combination) that a control can be applied to a risk. You’ve also already read the first two the GAIT principles , but there are more. Take a look at the third.
Notice how it says combination of controls can mitigate risks. Sometimes you can’t find a perfect control that completely manages your risk. However, using multiple controls, of all nine permutations, you can reduce risk to acceptable levels. In a combination of several controls being applied, there are hundreds of possibilities. You can also use overlapping controls to manage the same risk, if one control fails then the others hopefully can mitigate the risk. For example, if a firewall filters 80% of in-bound malicious executables, your user awareness training is 30% effective, and the workstation antivirus blocks 80% of the infections. Do the math on the effectiveness of these three different controls.3 Together these controls remove all but 3% of the infection attempts. Add a robust patching routine on browsers taking out another 80% and you’re doing better than 99%. This is called defense in depthand it’s a good way to layer your controls on critical risks.
Key Controls
If a control’s failure to eliminate a risk results in a failure of a critical business process, then that is a key control. In the audit world, if a control failure leads to not achieving a control objective, then that is also a key control. Key controls are a primary risk prevention tool, standing between your organization and a breach or failed audit. For this reason, key controls are usually preventative controls.
Since key controls are so critical, they should be as reliable and robust as possible. Since complexity can lead to unexpected behavior, simple controls are better. Also, key controls should be backed up by other controls in case they fail. This is also a form of defense in depth. For example, you have a control objective that no unqualified or dishonest personnel will be given access to IT systems managing financial transactions. Your key control could be pre-employment screening for previous criminal convictions as well as reference checks of stated credentials. Nevertheless, you can add a supporting control to ensure that this key control functions properly, such as a quarterly reconciliation of IT system users to HR records to ensure that no accounts were added without HR’s approval.
Compensating Controls
What happens when a compliance requirement mandates a specific control but you cannot implement that control? It could be for feasibility reasons, such as a critical legacy system that may not be able to accommodate a particular control. Some old mainframes are still in use to store and process payment cards but do not have mechanisms for strong authentication or encryption. Sometimes compliance-mandated controls can’t be implemented because of immense cost. For example, an organization may have built an entire network infrastructure using firewalls and switch appliances that only use a single user, forcing the entire IT team to share a single generic login and password.
This can be a serious problem for organizations facing PCI DSS, which has very strict requirements about implementing their control regime. Enter compensating controls, which are additional controls added to take the place of the required control. You should be aware that PCI DSS has the following criterion, which must be met for accepting compensating controls:
The controls must meet the same goal as the originally stated requirement (“intent and rigor”).
The control design must be at least as effective as the original control.
The compensating controls must be new additions. You cannot re-use existing PCI DSS controls from the same asset-risk pair as compensating controls.
The controls must over-compensate for the additional risk of going off required controls.
The compensating controls must work better than the original control. Often this works out to be either multiple additional controls or time-consuming administrative controls. This can mean that compensating controls can be more expensive and difficult to manage than original control requirement. In general, compensating controls work best as a temporary stopgap until the real control can be put in place. You will also need to explicitly document the reasons and mechanisms of these compensating controls and be prepared to defend them to auditors. Within the last few pages of the PCI DSS standard, there is a compensating controls worksheet that must be filled out.
Auditors review compensating controls with a lot of suspicion and ambivalence. You can expect your compensating controls to receive a lot of scrutiny. Even then, they may not be acceptable.
Control Functions and Failures
As you know from the concept of assume breach, the way that security systems fail is an important condition to consider during the design process. Many novice IT security practitioners become overly reliant on controls, especially technical controls. Consider commonplace technical security controls like firewalls and antivirus. In the beginning, these were considered optional controls that offloaded operational security work, such as hardening and patching. Now not only are these tools ubiquitous but also they are considered so essential that the idea of not using them is considered negligence. Like them or not, many IT systems are dependent on perfectly functioning technical controls.
Control Failure Modes
When analyzing a control’s failure state, consider what happens to its security functionality. Does a control fail open or closed? When it fails or becomes overloaded, does the control shut down the entire function it’s protecting or does it open up and allow all traffic to pass unimpeded? A control that fails open is useful if your primary concern is availability, but at the cost of access control. A control that fails closed will protect the assets behind it, even if it means shutting down the entire channel. Some hackers will flood traffic at network security devices that fail open, knowing that they can slip their attacks through once the shields are down. Other hackers may purposely overload network security devices for a denial-of-service of attack. You should make sure that your control’s failure mode matches your requirements.
Control Flexibility
Look at a control’s flexibility. In some ways, this is useful because the control can handle many different types of situations without a lot of pre-configuration. On the other hand, flexibility usually entails complexity. Complex systems are more prone to unexpected failures.
Control Functionality
Consider how the control works. Some controls work by what Marcus Ranum refers to as enumerating badness. This means the control has a long blacklist of known attacks that it will pattern match and filter against. This is fast and cheap to implement, which is useful for high-speed controls or for reducing complexity. However, there currently no complete list of every possible attack in the universe. All that attackers need to do is come up with one new attack that the isn’t on the blacklist, and they can sneak through. Some controls use lists of all acceptable behavior (white lists) and then filter out everything else. They are powerful security controls, as well as fast and cheap. However, they do require a lot of maintenance, because every time a new acceptable behavior is needed, it must be programmed into the control.
Lastly, some controls use anomaly detection to try to learn what is normal and acceptable, and then reject things that do not conform. These systems are also often complex (because they are flexible) and not always accurate (what is normal?).
For your controls, especially your key controls, you should look into all of these aspects. Based on the control functionality and its failure modes, you can decide if your design should include additional controls or high-availability options for technical controls.
Control Cost
Very few controls are fire and forget. Controls require care and feeding in the form of monitoring, patching, licensing, and adjusting. This is true whether a control is administrative, technical, or physical. Even policies have to be written, rolled out, explained, reviewed, and updated. This raises the question: What is the total cost of a particular control? What specific costs should you consider in costing a control? There are hard dollar costs like the following:
Purchase and licensing
Ongoing support and maintenance
Installation and testing (if hiring outsiders to do the work)
And there are soft costs, which can include the following:
Installation and testing (if using staff to do the work)
Disruption to work for users
Monitoring of functionality
User and administrator training
Documentation of configuration and functionality (at least for audit)
One way to look at control costing is to break out the cost per protected node per risk. For example, a firewall costing $10,000 may seem like a bargain, but not if it’s only protecting a small office of five users from network attacks only. There have been times where I’ve looked at my budget in this way. Let’s say that I have $100,000 to protect 500 users. That means I can expect to spend $200 per user, which needs to cover all of my risks and compliance requirements.
Some tools are licensed by the user, while others may require some thinking to break out. There have been times where a vendor has presented a security solution to me and I responded, “I am not paying $1,000 per host just for intrusion detection.” Having an idea of what your controls cost can help you make trade-offs in design.
Reducing the Cost of Controls
Since controls can get expensive, here are some ideas on how lower the costs.
Best Practices Can Be Expensive
What are best practicesfor security? There are lots of lists claiming to contain best practices, but for who and when? Remember that security and technology are constantly evolving. Any best practice list that cites specific controls and risks is likely to be obsolete soon after publication. I like to think of best practices as someone telling me, “This worked in our organization once upon a time, so it should work for you.” In other words, they’re precomputed risk/control trade-offs from somewhere else. Usually, they don’t include any accompanying data to back up their claim as to why they are a best practice. I’m sure that many of these controls are useful and may be relevant for your organization; however, considering that the average control framework of best practices has at least 80 specific controls, blind implementations can get expensive. If you are basing your security on a best practice list, make sure that you analyze each control to see how much risk reduction you’re actually getting for your money.
Legacy Systems
Securing old, but vital, legacy systems can get very expensive. Especially if you have to factor in software development to add security controls that don’t exist on the system. Even if you can get controls working on a legacy system, there may be higher-than-normal operational and support overhead to maintain. If it’s hard to put controls on the system, can you wrap the system in controls? Segment your legacy systems with firewalls, VLANs, and subnets. Then offer proxy or filtered access into the systems with lots of strong authentication and logging. In some ways, you can treat that legacy subsystem as its own scoped environment with its own policies and processes specific to access and operation.
Over Focus on Technical Controls
Technical controls are sometimes the most expensive controls of all. Not only in the cost of the technology and licensing, but also requiring skilled IT personnel to install, manage, and maintain them. A lot of technical controls can be replaced by solid processes and low-level IT work. Timely and continuous patching of software can be better than a sophisticated intrusion prevention system. An up-to-date accurate inventory and version management system can be as powerful as a vulnerability scanner. Change control policies and procedures can be very useful tools in hardening and managing deployed systems. Developer training can reduce security holes in software before they ever have to sit behind firewalls. Periodic log review and user access audits can control insider risks as well as many expensive management solutions. In the banking world, mandatory vacations for key personnel can help detect fraudulent internal activity.
Infrequently Used Key Controls
Key control failures can be expensive in terms of potential breaches and in audit findings. However, you may use some key controls only occasionally; for example, a quarterly reconcile of users to HR records, an annual software inventory, or a quarterly Internet vulnerability scan. If these controls are important, then it may be worth it to spend a little now to save more in the long run. If possible, spread out or increase the frequency of the key controls. This way, problems are caught earlier and a control failure isn’t as catastrophic. I’ve seen annual user-rights reviews where it was discovered that entire departments had full local admin privileges for the past ten months. Think about how much damage that could have caused. Doing the reviews quarterly, or even monthly, might actually be less effort, since the workload is reduced. When designing controls, there are a lot of ways for you to get creative—not only with the controls themselves, but also in combination with other controls. Maybe you can retain the annual review but add a scripted alarm to send an e-mail whenever a user is added to the admin group. There are many simple and cheap ways to bolster key controls. Even if you don’t know the answer, you can talk to your experts in the IT department.
Footnotes
3 Probability math: (1 – 0.80) × (1– 0.30) × (1 – 0.80) = 0.028 = 3%