INDUSTRY:  Manufacturing
SERVICES:  Forensic Acquisition and Forensic Analysis

Engagement Background

An executive for a global leader in manufacturing quickly realized he had a serious problem.  While in Shanghai to visit one of the company's Chinese facilities, his corporate laptop went missing.  The device containing a significant number of company documents and sensitive information was now unaccounted for, in China.  The device was not equipped with full disk encryption. 

Encryption converts data into unreadable code that cannot be easily deciphered without proper authorization.  With full-disk encryption, everything that could possibly reveal important confidential data, including swap space and temporary internet files, is encrypted.  With full disk encryption, the decision of which individual files to encrypt is not left up to users’ discretion.  This is important for situations in which users might not want or might forget to encrypt sensitive files.

When the device was mysteriously recovered 12 hours later (details undisclosed) the company's IT department wanted to quickly assess the potential damage of a data breach.  Their first call was to SecureState's Incident Response Team.


Why This Engagement Wasn’t as Cool as it Could Have Been

The keys to any quality forensic investigation (as you probably learned watching CSI) are to preserve the evidence and document everything.  SecureState worked closely with company personnel to create an image of the laptop.  SecureState then analyzed this image for potential unauthorized access.  While the company was worried that proprietary information was stolen, they were ultimately concerned with malicious software being installed on the system due to the fact that the laptop suspiciously reappeared.  Due to not having full disk encryption, it would be relatively easy for an attacker to bypass Windows authentication and access sensitive files or modify the system state in a malicious manner.

After carefully and meticulously analyzing every piece of data collected, SecureState was to put the client's concerns to rest, mostly.  The results showed no rogue processes, successful administrative-level compromises, or delivery of malicious software.  Additionally, no evidence indicated that unauthorized users successfully modified, stole, or intercepted sensitive data on the system or in transit. 


What the Consultants Had to Say

However, as the lead IR consultant points out, “due to the lack of full disk encryption on the system, it is possible that a malicious individual could have used a forensic boot disk or hardware write blocker to access the data on the drive and potentially pull the information off.  There just are no definite methods to prove if this was performed.”

Almost everyone has their own mobile phone these days. And they are quickly becoming a necessity in business, especially with executives. Nowadays, more companies are allowing their employees to bring their own device (BYOD). With BYOD, users have the ability to sync their work email, access company data, as well as use their phone or tablet for personal use. Let’s say a user loses their brand new iPad 3 on vacation after checking his work email. What can a company do to address the management of these mobile devices, and how can the company data on these devices be protected?

BYOD Freedom Requires MDM Security
In order to enable the kind of freedom BYOD brings, the corporate network and corporate data needs to be protected. Mobile Device Management (MDM) is a solution that will help with this kind of dilemma. MDM can be used on company owned devices and employee owned devices. MDM can help with the provisioning, securing, managing, monitoring, and supporting of mobile devices across the enterprise. All of the mobile device management can be done over-the-air. A traditional example of an MDM is the Blackberry Enterprise Server (BES). RIM was the first company to perfect the MDM infrastructure. Now modern MDM solutions can support more than just Blackberry. Actually, most vendors will support “the big three”: iOS, Android and Windows Mobile.

MDM Automation Eases IT Burden
Implementing an MDM solution does not have to mean more work. Automation can be an underfunded IT department's best friend. Small tedious tasks like software updates can be automated with most MDM solutions, removing some of the burden from the over utilized IT department. This kind of automation can also cut costs. Having fewer people working on mobility can lower IT overhead costs. In fact, some MDMs like Apple’s iPhone Configuration Utility are free and work well for a small scale MDM solution.

Proper MDM Implementation = Increased Security
Security has always been a concern when it comes to mobile devices on the network and the security landscape is changing, almost daily. Implementing an MDM solution will help with these security concerns. There are a number of solutions that will help with mobile policy enforcement like using a passcode in order to unlock the phone. In the case of a user losing their brand new iPad 3, a MDM solution can wipe the device over the air to help prevent data loss, or prevent an unauthorized user from getting at the data.

Choosing the Right MDM Solution for Your Company
When you look for an MDM solution, the solution you chose should be able to help you secure the data that is important to you. Functionality and security must also be considered. Your MDM solution should be able to work well across multiple platforms like iOS, Android and BlackBerry. Because most MDM solutions are still somewhat immature, there isn’t one product that will be able to do anything and everything.  However, as more mobile devices enter the enterprise and mobile devices become targets for attackers, evaluating and choosing a MDM solution is more important than ever for your business. 

Presentation: Practical Android Security

Abstract:
Building secure Android applications can be achieved with a mix of common sense, leveraging platform security features, and following secure development best practices. This presentation will focus on security “quick wins” during development and will cover techniques that can reduce the overall attack surface within Android applications.

The OWASP GoatDroid and OWASP MobiSec tools will be used throughout the presentation to demonstrate issues encountered in the real world. We will cover the attack surface for Android and highlight the most prevalent security flaws found within production applications.

Speaker Bio:
Jack Mannino is the CEO of nVisium Security, an application security firm located within the Washington DC area. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful application security initiatives.

He is an active Android security researcher, and has a keen interest in identifying security issues and trends on a large scale. Jack is the leader and founder of the OWASP Mobile Security Project. He also serves as a board member on the OWASP Northern Virginia chapter. Jack is also the lead developer for the OWASP GoatDroid Project, which is a collection of vulnerable Android applications used for training and education.

As always, OWASP is free and open to the public.
Lunch will be provided.
RSVP to Sabrina Powers by June 4th

Chapter Meetings
To join the chapter mailing list, please visit our mailing list homepage. The list is used to discuss the meetings and to arrange meeting locations. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes. Our chapter is sponsored by SecureState. The chapter leader is Ken Stasiak.

Would you like to speak at an OWASP Cleveland Meeting?
If we haven't approached you, but you believe you have new research that the security community would enjoy hearing about, we invite you to submit your presentation topic for consideration. Preference will be given to speakers who can present new and innovative technical content to a broad audience.
To speak at upcoming OWASP Cleveland meeting please submit your bio and talk abstract to Sabrina Powers.

Payment Card Industry (PCI) requirements 6.2 and 6.5.6, formerly best practices, become mandatory requirements for PCI Data Security Standards (DSS) compliance on June 30, 2012!

How will this affect our compliance with PCI DSS?
Organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the Cardholder Data Environment (CDE) as part of the on-going vulnerability identification process established in Requirement 6.2 and as part of their comprehensive Vulnerability Management Program.

Requirement 6.2 states that organizations must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.”

When developing a risk ranking or risk classification system, ensure that these systems are based upon industry standards or best practices.  The risk ranking assignment should classify risks in a manner which facilitates prioritization for remediation, such as a three tier model of High, Medium, Low or a decimal scale of 5.0 to 1.0.

What impacts does this have on our in-house or internally developed applications?
When application development is in-scope of an organization’s CDE, Requirement 6.5.6 will obligate testing against vulnerabilities classified as "high" risk as part of the secure application development process.

In essence, you will be required to develop your applications based on secure coding guidelines as required by Requirement 6.5. This includes preventing common coding vulnerabilities in software development processes as outlined within the sub-requirements of 6.5 and industry best practices like the OWASP Top 10. After June 30, you will also need to ensure your secure coding guidelines address “All ‘High’ vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).”

How else might this change impact compliance with PCI DSS?
A few other requirements are directly and indirectly affected by 6.2 and 6.5.6 becoming mandatory. They include:
• As new vulnerability issues are identified and risk ranked, you must verify that the system configuration standards and/or minimum security baselines (MSBs) required by Requirement 2.2 are updated.
• When performing quarterly internal vulnerability scans and remediation, you must continue the process until a rescan has passing results or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.
• When performing internal and external scans after any significant change, you must scan\rescan and remediate until:
o A passing result is obtained or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved (internal scans).
o No vulnerabilities exist that are scored greater than a 4.0 by the CVSS (external scans).

What to expect from your QSA
When a Qualified Security Assessor (QSA) is engaged to consult on your CDE, complete a PCI Gap Assessment, and/or complete a PCI Audit to issue a Report on Compliance (RoC) they will be looking for additional evidence related to requirements 2.2, 6.2, and 6.5.6. Some of the evidence will include:
• Your organization’s Vulnerability Management Policy
• Your organization’s methodology and process to assign risk ranking or risk classification to identified vulnerabilities
• Your organization’s system configuration standards and/or MSBs and documented change requests or completed changes as new vulnerability issues are identified and risk ranked
• Your organization’s quarterly internal vulnerability scans, rescan, and remediation steps between scans

Ranking risk an increasing priority
It is important to implementing a risk ranking system within your organizations' vulnerability management program and process. Remember, just completing your vulnerability scanning is not a vulnerability management program by itself. Vulnerability Management is an ongoing process to find, categorize, and address vulnerabilities in your environment. By taking proactive measures to ensure that proper controls are in place prior to the June 30 deadline, you can reduce the risk of falling out of compliance with PCI DSS v2.0.

INDUSTRY:  Insurance
SERVICES:  Wireless Assessment, Internal Vulnerability Assessment, Grey Box Web Application Security Assessment, and External Attack and Penetration Assessment


Engagement Background:

An insurance provider recently completed an Internal Audit of their IT security.  One condition of the audit was to have penetration testing performed by a third party.  The insurance company contracted SecureState’s Profiling Team to perform a Wireless Assessment, Internal Vulnerability Assessment, Web Application Security Assessment, and External Attack and Penetration Assessment.  Attack and Penetration Tests simulate an actual hacker attempting to gain unauthorized access to a company’s resources.  Penetration Tests are a much different process than a standard Vulnerability Assessment / Scan, in that once vulnerabilities have been discovered from either a manual or an automated process, SecureState will exploit the specific vulnerabilities or combine multiple vulnerabilities to achieve a larger attack (Vulnerability Linkage Theory).


Why this Engagement was Off The Charts!:
The results of the assessments were unsettling, in more ways than one.  In every assessment area, SecureState achieved full compromise of multiple systems.  In fact, the only thing that stopped SecureState was that they ran out of systems to break into.  Most of the methods used to compromise systems and locate confidential customer data were fairly basic attacks that a beginner could use.  The company employed full time IT security personnel, but it was clear that they were either unmotivated or unqualified.  The company’s internal auditor seemed to understand the severity of the problems and wanted the company to improve its security, but repeatedly backed down in what was one of our most confrontational closing meetings ever.


What the Consultants Had to Say:

“Upfront, they were pretty nonchalant about the findings.  But they quickly became defensive and pretty combative.”  They repeatedly argued semantics, “this vulnerability should be ‘high’ instead of ‘extreme’, etc.” rather than worrying about the fact that so many exploitable vulnerabilities existed on all of their systems.  “At one point, as one of the other consultants was walking them through the findings, the IT Manager yelled, ‘SHUT UP!’  He felt like we were piling on.” 
Besides the completely unprofessional behavior, what was really surprising is that an insurance company so misunderstood the security “insurance” model.  Their business is to help customers protect and mitigate against contingent risks, yet they didn’t realize that their failure to institute many basic security protections left them (and their customers’ data) uninsured against potential attacks.
Sure, they haven’t been breached yet (that they know of) but they “were the equivalent of selling auto insurance to a repeated drunk driver.  It is pretty much an accident that they haven’t crashed yet.”  As CEO Ken Stasiak puts it, “Our consultants strive to bring the most value to our clients.  We work with a lot of clients who get it.  These guys just didn’t get it.”

INDUSTRY:  Manufacturing
SERVICES:  External Attack and Penetration Assessment




Engagement Background:

Several months ago, a manufacturer’s product line drew the attention of a hacker collective, leading to a breach of the company’s externally facing website.  Both employee and customer information was stolen during the attack, which became public record.  Due to the resulting negative effects and publicity, the company has made information security a much higher priority and has been taking serious steps to improve their risk level.  They recently contracted SecureState’s Profiling Team to ensure these steps were in the right direction.  The Profiling Team conducted an External Attack and Penetration Assessment.  An Attack and Penetration Assessment attempts to breach the target as an unauthorized user with varying levels of access.  This is sometimes referred to as “red teaming” or “ethical hacking.”


Why this Engagement was Interesting:

The most interesting thing about this engagement was really the company’s products and the circumstance that brought us there.  The company had a really small services footprint and their external website was hosted externally.  For that reason, they hadn’t given much consideration to information security in the past.  However, they quickly learned that when skilled and dedicated hackers decide to focus their efforts on a target, without taking necessary countermeasures, a breach is inevitable.

The engagement itself was fairly routine.  SecureState attacked one external IP address and found it to be reasonably secure.  Of the four total vulnerabilities found, only one was even a potential high risk vulnerability, relating to a Microsoft patch.  The client went about remediation immediately.


What the Consultants Had to Say:

“It was refreshing to work with a client who had already addressed almost all our findings before we even did the closing meeting.”  It was clear this company took the breach (and potential for future breaches) seriously, and really wanted to prevent it from happening again.  “When the closing meeting was over, the Project Lead thanked us and said it was a pleasure to work with us.  The feeling was mutual.”

Having spoken at both at the SANS Mobile Device Security Summit as well as OWASP AppSec DC recently about testing mobile applications I’ve encountered that like the old saying goes “There are many ways to skin a cat”, there are also many ways to assess a mobile application.  I’ve seen very detailed testing methodologies, not so detailed and everything in between.  I’ve also heard other security professionals say that testing mobile applications are just like testing a web application.  This is simply a wrong and inaccurate statement.  Mobile applications are fairly complex and just assessing the application layer is only a small look into the overall security of a mobile application.  While the OWASP Mobile Security Project will help define a complete mobile application testing methodology (which is in process), here are three areas that need to be tested in every mobile application.

1. The Mobile File System
How’s the application storing data and where is it being stored?  You’d be surprised how much information is being stored in files, SQLite databases, system logs and more.  If you’re lucky you will sometimes find private keys and hardcoded passwords.  As a great example, the mobile Facebook application suffers from a file system vulnerability as I write this.  The author likes to call this a “plist hijack attack”.  Simply move the plist file to another mobile device and you are logged in as that user.  As for tools to use when looking for file system vulnerabilities you should really check out the forensic approach that John Sawyer from InGuardians has developed.  It’s my preferred method for seeing how the app writes to the file system and saves lots of time over creating a dd image.

2. The Application Layer
How’s the application communicating over HTTP?  How are web services being used and how are they configured.  Important things such as authorization and authentication need to be reviewed as well as session handling, business logic, input validation and crypto functions.  Business logic needs to reviewed just like you would in a Web Application Assessment to find flaws in the way critical functions (like shopping cart checkout processes) were developed.  Remember to never under estimate the criticality of Web Services!  For reference and context, check out the presentation that Josh Abraham, Kevin Johnson and I gave at Black Hat USA last year.

Something else worth mentioning is that you can’t rely on traditional web proxies like Burp Suite to test the application layer on a mobile app.  I’ve encountered applications that are configured to bypass device proxy settings!  You need to use a tool like Mallory which is a fantastic TCP and UDP proxy.  Mallory sees all traffic and allows you to manipulate and fuzz it.  There are other ways to do this as well but regardless, you need to have a way to see all traffic the mobile app may generate.

The application layer is also where you need to look for issues specific to mobile applications like UDID usage in iOS.  UDID is currently being used by many applications for unique device identification.  However, the use of UDID is becoming an increasing concern from a privacy perspective.  Not to mention, Apple is cracking down on UDID usage by now denying applications in the Apple App Store.  Check out the presentation I did at OWASP AppSec DC this year about some of the privacy and security concerns regarding UDID.

3. The Transport Layer
How does the application communicate over TCP?  How are custom protocols and third-party APIs used?  Does the application use SSL?  At OWASP AppSec DC we talked about the LinkedIn mobile application that was vulnerable to “sidejacking” or better known as HTTP session hijacking.  This is where an attacker can pull out the session cookie in clear text and replay this so the attacker can login as the user.  The popular “Firesheep” tool released in 2010 demonstrated this nicely.  The good news is that the recent release of the LinkedIn app (version 5.0) fixes the sidejacking issue.  Unfortunately though, using SSL for just the login process and defaulting back to HTTP is an issue many mobile and web applications still have.

Mobile Application testing is something that will evolve as mobile apps get more complex and the business drives more towards mobile solutions.  If you’re deploying mobile apps for your business it’s more important than ever to have testing done on these three areas at a minimum. Lastly, keep up-to-date on the latest developments on Mobile security and testing methodologies by getting involved with the OWASP Mobile Security Project.

Physical security is a very important and often overlooked piece of the information security puzzle.  The diagram below shows how Physical Assets fit in:

Many organizations try to ensure that their information is safe from a digital attack, and they should.  However, what happens if the attacker can walk into the facility unchecked and walk out with a backpack full of sensitive information that was sitting in an unlocked filing cabinet?  As a member of the SecureState Profiling Team, I perform Physical Penetration Tests, and they are always eye-opening experiences.  These are just some of the things to be aware of at your organization.

1. Attached Parking Garages
• These garages are often publicly accessible and not guarded or monitored.  They can provide unauthorized access to internal areas of your facility.
On past assessments we have used attached parking garages to great success.  It is very convenient for us to park and take the elevator down to the lobby of your facility.  While walking out to the street we can notice camera locations, guard stations, etc.  When going back to the car we have another opportunity to notice additional things.  These garages are also a great place to sit quietly and observe employees coming and going.  Many times we overhear a sensitive conversation or get a good look at an employee ID which we can use later.

2. Unprotected stairwells
• Internal stairwells should be locked or be protected by some form of access control (access card or code).
On a recent assessment we initially used the elevators to move between floors.  However due to heavy employee activity on the elevators, we opted to exit at the next stop and proceeded to use the internal stairwell to move around.  We had unchecked access to every floor, including the roof.  Had the stairwells been access controlled, we would have been forced to have much more interaction with employees and would have been more likely to be noticed.

3. Employee Awareness
• Employees need to be aware of their surroundings.  They should be mindful of tailgating into protected areas.

• Employees should challenge anyone who requests access to protected areas by checking or looking for IDs and verifying visitors with a supervisor.  Many companies fail to implement a policy that requires employees to wear their badges so they are able to be seen.

This is something we are able to take advantage of on just about every Physical Penetration Test.  Most people are quick to hold the door for whoever is behind them, even if they don’t recognize them.  We even had an employee from behind the doors open them for us and ask if we needed in.  On another assessment, we were stopped by multiple employees in different parts of the facility.  We were briefly questioned but never asked to supply any ID, and they never called their supervisor to verify our stories all because they didn’t want any conflict.

4. Unprotected Hard Copies of Sensitive Information
• Lock the filing cabinets.
• Don’t leave confidential information unsecured and easily viewed.
This seems like a no-brainer.  Don’t leave documents with sensitive internal procedures or PII / PHI on your desk unattended.  Furthermore, if you store paper documents in a filing cabinet, keep it locked.  People are much more likely to notice a person trying to pick the lock on a filing cabinet as opposed to just walking up and opening it.

5. Inattentive / Ineffective Security Guards
• Guards should be making rounds and actively watching cameras.
• Guards should be periodically tested to ensure they are doing their job.

On our most recent assessment, we were able to walk right through the front door because the guard was on their lunch break.  While moving through the building we did not encounter any guards making rounds.  In fact, we did not encounter any guards until we left the building, again through the front door.  Had the guards been making rounds through the building, or watching the security cameras, they probably would have noticed some of the things we were doing.

Many of these concerns are directly related to convenience.  It may be a small burden to badge in and out of office areas and stairwells or to require a key for access to storage, but that extra step can go a long way towards improving the security in your organization.  Additionally, it may be your corporate culture to hold the door for people entering behind you, or not to challenge visitors who are in protected areas.  Those polite gestures can come with a risk, and there should be a corporate policy in place to address these things.

We are able to complete our assignments easily due to these and other issues, all of which could be prevented quickly and with relative ease.  Had we been real attackers, the target organizations would have suffered very tangible losses that they would not have been immediately aware of.

Principles which apply to network and application security also apply to physical security.  Vulnerabilities need to be identified and verified, and risks need to be mitigated.  SecureState offers both a Physical Attack and Penetration Test and a Physical Security Assessment.  Both of these offerings can help find the risks that can affect your organization and a path to mitigate them.

INDUSTRY:  Manufacturing
SERVICE:  INFOSEC Assessment with External Vulnerability Report

Engagement Background:
A large Midwest manufacturer contacted SecureState to help identify vulnerabilities in their network security and to assess their security program as a whole.  Our RM and Advisory teams were brought in to assess the existing security controls and make appropriate recommendations to mature the security program.  The Risk Management team performed an External Vulnerability Assessment, a focused and controlled vulnerability analysis of the external Internet presence.  The analysis consists of deploying multiple vulnerability scanning engines to identify potential security exposures within Internet facing systems.  Additionally, our Advisory team executed an INFOSEC Assessment to gain insight into their Security Program as a whole, as well as provide a better understanding of the root causes behind findings from the Vulnerability Assessment.

Why this Engagement was Different:
The External Vulnerability Assessment revealed a number of significant vulnerabilities, including an extremely exploitable Telnet server accessible using default credentials.  The client didn't seem particularly impressed or concerned.  They felt the Vulnerability Assessment didn't take into account company priorities and the importance of the systems that were vulnerable.  Under normal conditions, a SecureState INFOSEC would help provide this important context.  However, the client also requested a significant narrowing of the INFOSEC scope, to focus on IT areas only.  Doing this saved them a little money, but significantly diminished the value of the assessment.

What the Consultants Had to Say:
"I was already onsite.  It isn’t a big difference in time or expense to add the full assessment and allow me to talk to all the right people in the organization and provide them with full recommendations."  This engagement really highlights how SecureState is different than most security companies.  We view information security as a whole and from a strategic level.  We can put it all together.  "It is very easy to put the right rules into your firewall.  It is harder to implement policy to make sure that someone is consistently inputting the right values, and checking them."  A full SecureState INFOSEC Assessment can help your organization put all the pieces together and assist you in making the right security decisions every day.  "They really just wanted validation that what they were doing was fine." 

It always surprises me to find how many organizations believe that a vulnerability scanner is equivalent to a Vulnerability Management Program. A vulnerability scanner can be of great help to a Vulnerability Management Program, but a scanner is just one component of a Vulnerability Management Program. Equating Vulnerability Scanners to Vulnerability Management Programs is similar to equating steering wheels to cars. No one would argue that a car isn't made of many more components than just a steering wheel. Similarly, Vulnerability Management Programs are made of many more components than just a vulnerability scanner. Do cars need steering wheels? Absolutely. Are steering wheels cars? Absolutely not.

How Vulnerability Scanners Can Help (Frodo...Maybe I can help carry the ring for a while?)
In addition to the ability to scan devices in order to find technical vulnerabilities, many vulnerability scanners come with a lot of really great tools. These tools can greatly assist with the development of a solid Vulnerability Management Program. I have especially been impressed with the Qualys and Nexpose tools that help with asset classification (which ties into reports used for prioritization of remediation efforts), reporting, and ticketing systems.

• Asset Classification Assistance Tool - Asset Classification is extremely important to a Vulnerability Management Program. Assets must be properly classified in order to prioritize remediation efforts. Asset classification is also important when it comes to determining the true impact the exploitation of a particular vulnerability will have on the organization. Both Qualys and Nexpose provide tools that enable someone to set the criticality of a particular asset or asset group. Reports can then be run that correlate asset criticality with identified vulnerabilities. These reports can then be used in order to assist with prioritizing remediation efforts.

• Reporting - Both Qualys and Nexpose have extensive reporting capabilities. These reports can be very helpful when the organization needs to review how the scanner identified a particular vulnerability (this helps with eliminating false positives and validating that a vulnerability has been remediated), providing information on how to remediate specific vulnerabilities to internal personnel, performing vulnerability trending and analysis, and tracking vulnerability remediation efforts.

• Ticketing Systems- Both Qualys and Nexpose have ticketing systems. Ticketing systems can be used to track vulnerability remediation efforts. Ticketing helps with tracking what vulnerabilities are open and what vulnerabilities have been closed, determining the current threat posture of the organization's eternal and/or internal networks, and how long it takes to remediate specific vulnerabilities.

All of these tools have their place in a solid Vulnerability Management Program, but even with all these extra bells and whistles, they do not equate to a Vulnerability Management Program.

What Vulnerability Scanners Cannot Do (I am a Vulnerability Scanner and I cannot create round squares or married bachelors)

Vulnerability scanners are part of every solid Vulnerability Management Program, but there are a number of things that a vulnerability scanner cannot do. Just to name a few, vulnerability scanners are unable to actually classify assets or determine service level agreements for remediation efforts, determine who needs to remediate what vulnerabilities, or perform root cause analysis.

• Asset Classification - Tools may be used to track asset criticality, correlate asset criticality with identified vulnerabilities, and track the remediation of vulnerabilities on critical assets, but in the end, the tool is unable to determine the actual criticality of a particular asset. The data needed to determine system criticality must be provided by a security professional. Asset classification is not always a straight forward process. Things like business impact, the kind of data being stored/processed/transmitted by the system, and cost per minute of downtime, etc. must be considered when determining asset criticality. To give just a few examples, asset classification should tie directly into SLAs for system downtime, the level of testing patches and configuration changes must go through before being applied to production systems, and how long internal personnel have to remediate a specific vulnerability on a specific system. These tasks are normally tied into and enforced by policies and procedures. A tool is unable to create and/or enforce policies and procedures. The creation and enforcement of such policies and procedures must be performed by internal personnel (Or at least until Skynet rises).
 
• Asset Ownership - I could use a tool and program it in such a way that when a vulnerability is discovered on "Server A" it sends a notification to "Person X". Although a tool can follow these instructions it is unable to provide the initial conditions needed to send these notifications. In addition, if "Person X" leaves the organization, the tool does not understand that it needs to update the point of contact to "Person Y". Asset ownership cannot be determined by a tool. An actual human must perform this task.

• Root Cause Analysis - Without root cause analysis there is a great chance that vulnerabilities that one scan identifies will continue to re-occur on a regular basis. A vulnerability scanner cannot determine if the organization's patch management program is flawed, or if the organization has Minimum Security Baselines policies in place to require patches to be applied to all servers before they are placed in a production environment. Vulnerability scanners can provide data regarding specific vulnerabilities that it identifies, but it takes trained security personnel in order to properly trend the vulnerability scanner's findings and determine the root cause of the problem.

Conclusion (Death is a natural part of life. Rejoice for those who transform into the Force)
Although vulnerability scanners can greatly assist in a Vulnerability Management Program, we should realize that they are not the program itself. Vulnerability Scanners in and of themselves can do nothing to improve the organization’s security posture. A Vulnerability Management Program combines vulnerability scanners with knowledgeable security personnel and solid process, policies, and procedures. Great Vulnerability Management Programs can take time to build, but can greatly benefit your organization.