I think it’s safe to say that most penetration testers prefer the testing aspect of their role to the reporting aspect. When I interview potential candidates, very rarely are they the first to mention report writing. We talk about passive enumeration, active scanning, exploit writing, shellcode, Shodan, Maltego, all the “fun” stuff. But report writing is vital, it is the deliverable. If the client cannot receive a useful penetration test report, then there is no value in the service. All too often, report writing is –sadly- seen as the bit you have to do at the end. And so it is with much of the important aspects of Information Security.
I was recently in a PSN health check wash-up meeting with a client that has a large IT department spanning a wide array of IT disciplines. As things drew to an end, one of the network team asked if an extra firewall should be installed into the network to segment two specific groups of users. When I asked what the risk assessment indicated, an immediate look of confusion fell upon my client’s face. “What about best practice?” he asked. Well, best practice for who? For what security appetite? Arguably, best practice would be to simply say yes. But ISO 27001 and many other standards, teach us that over-controlling risk is not a path to success.
Many organisations to this day, fail to implement a workable Information Security Management System. Often, due to the perception that it generates an endless mountain of paper, and thousands of wasted hours of staff resource. This is simply not the case. In fact, a properly implemented ISMS will ensure the efficacy of information security controls.
So what does an ISMS look like? In it’s simplest form, an ISMS need be little more than:
1. A security policy
This is nothing more than a mission statement. It needs to contain SMART objectives (Specific, Measurable, Assignable, Realistic, Time-Related). If objectives are not SMART, then the ISMS’ effectiveness cannot be measured.
2. A framework for risk-assessment
Most organisations already perform risk assessments on a wide range of risks, from business risks, to health and safety. It is not a new concept; in fact, it is intrinsic to human behaviour. The basis of a risk assessment methodology states:
- What, in financial terms, does the organisation consider a low/medium/high impact?
- How will threats be identified and calculated?
- How will vulnerabilities be considered?
- What does the organisation consider acceptable risk (the risk appetite)?
In its simplest form, Risk = Threat x Likelihood x Impact
This is oversimplifying things, and risk assessment is far from a precise science, but most people stopped in the street would agree that a typical server has more chance of being contaminated with malware than struck by lightening.
Identifying Threats can take some time, because the Threat alone is nothing without a motivation and a vulnerability. In other words, the Threat has to qualified before it is a Threat:
3. A comprehensive list of information assets
An information asset can be anything, from a member of staff, to a software license, a third party supplier, or a database. Each asset will have a value for the loss of Confidentiality, Integrity and Availability.
4. Risk assessment and control selection
Now we get to the useful part. Each information asset is risk assessed using the above framework. We can identify the impact of a successful Threat/Vulnerability combination, potential controls to prevent an occurrence and the on-going measurement of selected control’s effectiveness.
5. On-going monitoring
The ISMS is a living, on-going process. It requires on-going monitoring and modification to cover new threats, vulnerabilities and controls, and the review of existing controls for effectiveness.
Why bother?
This may seem like a lot of work, but it typically isn’t. Once the framework is in place, risk assessments become relatively straightforward, enable the greatest risks to receive the lions share of control resources, ensure that all feasible threats are considered, and enable an accurate risk register to be built. Without these tools, organisations will almost always miss potential risks, over and under control identified risks, and misallocate information security resources.
So the question of whether a firewall was needed, isn’t really a case of best practice, it’s a question of risk assessment, which should come from within.