When assessing the security of any environment, the first few hours are the most important. Depending on the organization and its security awareness, these first stages of the assessment will introduce many of the vulnerabilities or security issues that will dominate and direct the next few days. The client’s technical authority (or project sponsor) must be nearby to discuss any preliminary findings.
With ready access to the client’s technical authority, the consultants can discuss the findings and learn how the organization manages risk. For example, the discovery of vulnerabilities that reveal missed patches on Oracle database servers may relate to the fact that different departments are responsible for the security of these hosts and, unlike the Solaris Services team, the Database Services team may have a two-week turnaround for the application of “critical” patches instead of the organization’s standard four days.
Information gleaned from this type of discussion is important if the security consultants are to deliver a final report that is of maximum value to the client. Discovering and presenting a list of the vulnerabilities and missing patches is great but true value lies in understanding the context of the vulnerabilities and then getting expert advice on how to secure the environment against threats.
Issues identified early in the assessment will influence the remainder of the testing as well as the final report. By understanding how the client manages and operates the environment being assessed the consultants can ensure that appropriate advice is given.
Let’s look at the example above. Here, the consultants may have identified lapses in security responsibilities for the Oracle servers. These may be easily corrected through minor procedural changes for one of the service teams. The changes would increase their Oracle defense in-depth posture. The security consultants could then provide expert advice on patch management processes and response-time evaluation techniques. In this way, the security consultants can focus on providing security advice instead of repeatedly highlighting the same security vulnerability.
Discussions held with local staff as the first results filter in can be used to better understand the organization’s overall security awareness and posture. Key to this awareness is understanding where the staff perceives the threat to be.
While there are numerous statistics about whether the greater threat is from external or internal attack vectors, many non-security professionals who manage these environments have no real understanding of how and why someone would exploit a security weakness in their systems.
Too often, clients have failed to grasp the threat levels in their environments. Clients focus on external threats (the usual “I have a firewall therefore I am secure” discussion) and then they log everything they possibly can.
I am surprised at how often clients experience an epiphany when I point out that if anyone really wanted to target their organization at a professional level, the ideal way would be to be temporarily employed in the development team. A temporary employee could have full access to everything, and most developers can convince the helpdesk to grant them administrative permissions on their workstations (gaining the ability to install required hacking tools).
By ensuring that the client’s technical people are at hand at the start of the assessment, beneficial knowledge transfer can begin. Nothing beats having the client sitting next to the consultants asking questions as they proceed. The client’s technical staff benefit by understanding how a hacker would operate, and can see how easily certain “confidential” information can be gained. The staff can then add perspective to the findings as they emerge and the consultants can focus on areas that have the most significance to the client.
Early assessment discussions can also shift the focus of the security advice as issues are uncovered. For instance, in a previous assessment, informal discussions over whether the systems under test had any mechanism to log or identify attacks revealed that the server teams all thought that it was someone else’s responsibility. It was discovered that nobody reviewed the event logs, nor did any group actually possess sufficient access permissions to view them.
This information was important, as the client had requested that advice be included within the final report as to whether a proposed IDS system would increase the security of the environment. Since the firm didn’t have procedures or resources to handle the security event information it was generating, an IDS system would have been superfluous. Instead, the client needed to first invest in processes and tools that make event log management manageable.
I am a strong proponent for ensuring the client’s technical staff and consultants work closely on any technical security assessment. The client’s technical staff benefits from the knowledge transfer, making their jobs easier. The consultants gain the opportunity to provide truly useful security advice to the client. Working together guarantees that the final report will be a valuable – and lasting – document.