Orientation from the Start
First Published: SC Magazine

When assessing the security of any complex environment, the first few hours are typically the most important. Depending upon the client organisation and their general security awareness, these first stages of the security assessment are likely to throw up many of the vulnerabilities or security issues that will dominate and direct the next few days work. It is therefore very important that the clients technical authority (or even project sponsor) be at hand to discuss these preliminary findings as they are identified.

With ready access to the clients’ technical authority, the consultants can discuss the findings and gain a greater insight into how the organisation evaluates and manages risk. For example, the discovery of vulnerabilities that are indicative of missed patches on their 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 require a two week turn-around for application of “critical” patches instead of the organisations standard 4 days.

This type of discussion and understanding is important if the security consultants are to deliver a final report that is of maximum value to their client. It is all very well presenting a list of all the vulnerabilities discovered during the engagement and highlighting missing patches on individual hosts, but the real value to the client is in understanding the context of the vulnerabilities and the provision expert advice on how to secure the environment against current and future threats.

Identifying the issues behind the first few hours of security findings will greatly influence the remainder of the assessment and the final report deliverables. By building up a greater understanding of how the client manages and operates the environment under study, the consultants can ensure that appropriate technical security advice is made. For instance, continuing the earlier example, the consultants could distinguish lapses in security responsibilities for the Oracle servers which may be easily corrected through minor procedural changes for one of the Services teams that would increase their Oracle defence 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 pointing out the same security vulnerability.

These initial discussions with the client, as the first results filter in, can be used to better understand their organisations overall security awareness as well as posture. Key to this awareness is in understanding where they perceive the direction of 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.

All too often, as I enter into discussions with the client, they have failed in the past to grasp the relative threat levels associated with their environment. Their typical focus is upon external threats (the usual “I have a firewall – therefore I am secure” discussion) and logging everything they can. I am still surprised at how often the client has a “light bulb” moment when I point out that if anyone really wanted to target their organisation at a professional level, the ideal way would be to submit a CV and get a short-term contract job in their development team. That way they would have pretty much full access to everything, and most developers can usually convince helpdesk to grant them administrative permissions on their own workstation (thereby gaining the ability to install whatever hacking tools they require).

However, by ensuring that the clients’ technical people are at hand at the start of the assessment, the fruitful process of knowledge transfer can begin. Nothing beats having the client sitting next to the consultant asking questions as they go along. The clients technical staff benefit immediately by understanding how a hacker would go about their business and can clearly see how easy certain “confidential” information can be gained. They are then able to add perspective to the results as they begin to roll in, and the consultants can focus upon areas that have the most significance to the client organisation.

These early discussions can also shift the focus of the security advice as other 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 (successful or otherwise) revealed that the different server teams all thought that it was someone else’s responsibility. Eventually it was discovered that nobody reviewed the event logs, nor did any single group actually possess sufficient access permissions to view them. This new information was important as the client had requested that advice be included within the final report as to whether a previously proposed IDS system would increase the security of the environment. Since they didn’t have procedures or resources to handle the security event information they were currently generating, an IDS system would have been superfluous. Instead, as a first step, they should invest in processes and tools that made event log management more manageable and assign appropriate resources to the task.

It is for these reasons I am a strong proponent for ensuring the clients technical staff and my security consultants work closely on any technical security assessment. The clients technical staff benefit from the knowledge transfer, making their jobs easier. For the consultants, they gain the opportunity to provide the level of security advice that really does benefit the client organisation in the long run. Working together, the final report deliverable is guaranteed to be a lasting and more valuable document.

    Copyright 2001-2007 © Gunter Ollmann