The kings and barons of history sought security in heavily fortified castles. There might be a central keep with a surrounding wall, all on top of a mound; perhaps with a moat as well. Of course, there also had to be a way to get in, hence a door, heavily fortified within a gatehouse, maybe including a portcullis and drawbridge.
Part of the essence of such designs was simplicity – it was much easier to defend one door than to defend many. Designing a secure fortress was a specialised skill but it is not beyond most of us to understand how such security worked. But what about the IT systems we rely on today? Are they too complex to understand and how does that affect their security?
A quick visit to Google shows that I’m not the first to raise this question but on-line discussions quickly lead the reader into the realm of abstruse papers around complex systems and complexity theory. Here I aim to take a more pragmatic approach based on experience working with many clients of varying size and with reference to PCI DSS, the payment card industry’s data security standard, since that is the focus of much of my current work.
I think it is clear that it is far beyond even an IT security specialist to have a full understanding of all the security issues and vulnerabilities that may affect the variety of IT systems in use within many organisations. It is for precisely this reason, that within companies like 7Safe and PA Consulting, you will find people who specialise in penetration testing, web site security, database security, network security and so on. Even within such specialisms though, some people will be more familiar with, say, one brand of firewall than another.
The inability for anyone to be an expert in all things must compromise security. Often complexity leads to disagreements about the best way to secure a particular situation. I often check out various on-line fora for an expert view on some security matter and I am frequently surprised how hard it is to find clear answers. Contributors, who are evidently both qualified and experienced with the relevant technology, still put forward varying views on what is best security practice. What chance does the average organisation have of implementing everything in a secure manner?
Complexity within the infrastructure architecture is one problem; complexity within software is another. The regular discovery of vulnerabilities within common operating systems and applications is also a direct result of the complexity of the code. Business imperatives other than security may mean that we have little alternative than to use this complex software but does that have to leave us helpless?
I believe that that organisations can address the problem of complexity through a virtuous circle of understand, simplify, standardise. Interestingly, this approach is implicit within PCI DSS.
Firstly, if vulnerability may increase from a lack of understanding due to complexity then anything that can be done to improve understanding must be beneficial. One of the first steps required for PCI DSS compliance is that a merchant defines the scope of the card holder data environment (CDE) for compliance. This includes charting the cardholder data flows and defining the boundaries of the CDE. One requirement is for a current network diagram but any PCI specialist will testify to how often organisations are unable to produce such a diagram. Yet the network cannot be defended if it cannot be documented.
Further, many are unable to identify all the flows and storage locations of card holder data and it has a way of creeping into unexpected locations. Again, it cannot be secured if its presence is unknown, which is why PCI requires some form of data discovery exercise as part of the scoping phase.
The first step towards addressing complexity is to keep your understanding of the environment up to date. Updating network diagrams as you make changes is easier than preparing them retrospectively.
When the documentation is complete, it often reveals another complexity issue. Systems and processes grow over time, new technologies emerge but old ones are not discarded, tactical solutions are implemented, business units use non-standard technologies without reference to corporate IT. For example, one organisation, implementing a secure area for PCI, identified a variety of logging and monitoring tools, many of which were now obsolete, but each of which could have opened a way into the secure area. Further, examining its whole payment flow gave the opportunity to decommission several elements of the process and to outsource others.
Simplifying by maintaining control over development and re-architecting rather than constantly adding can reduce vulnerability with the likely additional benefit of reducing cost.
Closely related to simplification is standardisation. This is another aspect recognised by PCI DSS with its requirement for standardised build configurations for all types of devices. Devices configured with only the minimum of applications and services installed and enabled present fewer opportunities for attackers and are easier to manage. Organisations such as the Center for Internet Security (CIS) and National Institute of Standards and Technology (NIST) publish standardised device configurations that organisations can adopt. Microsoft also publishes baseline configurations for various purposes.
Standardisation then completes the circle back to understanding. An organisation with a limited, standardised set of hardware and software configured in a standard manner has a better chance of understanding any vulnerabilities that exist, making it easier to monitor and secure them.
ICT is inherently complicated and, if we ignore the argument for security through obscurity, that complexity makes it insecure. Only by seeking to improve your understanding of what you have and where it is through simplifying and standardising will you really be in a position to implement securely.
To find out more about PCI DSS, or how 7Safe can help you achieve or maintain compliance, please contact us.