The guide is a comprehensive, and easy-to-understand tool to help providers and professionals integrate privacy and security into their clinical practice and includes sections addressing:

I especially liked the Security Risk Analysis Myths and Facts section in Chapter 2!  An example:

Myth: A checklist will suffice for the risk analysis requirement.

Fact: False. Checklists can be useful tools, especially when starting a risk analysis, but they fall short of performing a systematic security risk analysis or documenting that one has been performed.

Full Guide: Check out the full Guide to Privacy and Security of Health Information: http://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf.

Contact Pondurance if you would like help with your HIPAA/HITECH risk assessment.

Steve Lodin is a consultant with Pondurance and has been a CISSP since 1998.

I recently had the opportunity to help a client perform a risk evaluation on Microsoft Security Bulletin MS12-020 related to RDP vulnerabilities that could allow remote code execution without authentication.  It was rated at Critical by Microsoft.  At the time of release, it was suggested this would be a potential for large scale exploit.  Shortly after release of the security bulletin, proof-of-concept exploit code was released.

The evaluation flowchart below helped our client define their timeline for patching, either immediately or during normal monthly system maintenance depending on answers to the questions in the risk evaluation process.

Hopefully the Patching and Vulnerability Team in your organization evaluates critical security bulletins and vulnerability announcements in a similar way to determine applicability, scope, and risk in your environment.  Having a risk evaluation process embedded in your team, plus simple tools like this should ensure that (1) you don’t miss the critical stuff and expose your systems to threats needlessly; and (2) you don’t over-react and become the boy who cried wolf.

Contact me if you want the Visio diagram below to seed your next critical security bulletin evaluation.

Definition of Accessible

The system can be accessed by systems on the Internet or by business partners through a firewall.  Accessible by systems internal to client is not in scope.

Definition of NLA

Network Level Authentication is an authentication method that can be used to enhance RD Session Host server security by requiring that the user be authenticated to the RD Session Host server before a session is created.

Network Level Authentication completes user authentication before you establish a remote desktop connection and the logon screen appears. This is a more secure authentication method that can help protect the remote computer from malicious users and malicious software.

http://technet.microsoft.com/en-us/library/cc732713.aspx

Steve Lodin is a consultant with Pondurance and has been a CISSP since 1998.

Simply stated, documented policies contemplate management’s strategic direction for all things relevant to control and governance.  A well-documented policy establishes the level of intent to which management will extend its…well, its management.  The complementing, documented procedures provide the means for execution by organizational staff, while the documented standards further convey the acceptable, and sometimes prescriptive, means to achieve certain control objectives.  All of that is a fancy way of saying: “write it down and do it…and when you do it, do it like this.”

So let’s readdress the question of what documentation really accomplishes, particularly if it is prone to collect dust until an auditor pays a visit.  The reality is that good documentation creates a culture for precision based execution.  It’s not simply putting words on paper…it’s putting words on paper that provide a measure for controlled success.  But we can boil that down further by considering the three “Cs” that are the product of well-managed governance documentation:

Compliance

The truth is…auditors simply adore documentation.  For the inexperienced auditor, it may simply be rote acknowledgement (i.e., “check the box”) that the documentation exists.  The good auditors will, however, acknowledge that management has thought well enough to develop a framework of intent that may be in line with either industry practices or regulatory standards.  The good auditors will then proceed to choke you with your own words if they sense that there is an imbalance between the paper and the implemented process.  So, while documentation does indeed “check a box” for your auditors, be sure that the contents of that box have not spoiled.  If you can maintain up-to-date documentation, and you can gain reasonable assurance that staff are familiar with the policies and procedures, you are at least positioning yourself to achieve regulatory or industry compliance.

Consistency

Another truth is…documentation provides the means for consistent execution of control procedures.  Ad hoc procedures tend to drive operating risk to unacceptable levels, particularly when precision is required and, perhaps, sensitive data is at stake.  Think of this simplistic, albeit relevant, example that relates to security:  Let’s say your organization does not have a documented policy and commensurate procedure regarding Emergency Access.  If I employ social engineering techniques that use fear as a method to gain system access under the auspices of an emergent situation (i.e., I’m a doctor and the life-safety of a patient is at risk), and the poor help desk technician has not been trained on (nor is able to reference documentation to) the proper procedure to provision system access under those conditions, the result may lead to unauthorized access.  Another situation might be the lack of restorative procedures for data that is backed up on either disk or tape…if the technical staff has not documented the process, a critical step might be missed and the restoration process may fail.  Consistency is king when considering either procedural or technical control execution.  If standards for such controls are not documented, and updated as necessary, there is a greater propensity for inconsistent execution and even control failure.

Continuity

The final truth is…people should be considered as potential single points of failure.  When certain people leave the organization, whether expectedly or unexpectedly, it goes without saying that they will take with them a great deal of knowledge.  If at least the critical portion of their working knowledge is not documented, then most assuredly they take with them much more than the organization could possibly stand to lose.  I have evaluated many organizations that roll the dice and place deep reliance on a single person without so much as creating even a basic succession plan.  While it is not prudent to document the expansive details that comprise all work activity of a specific person, it is certainly less prudent to exclude all forms of documentation.  When it comes to control procedures and standards in particular, an ounce of ink is worth a pound of continuity.

Ron Pelletier is a partner with Pondurance, a Certified Business Continuity Professional (CBCP) since August of 2000, and a Security, Continuity and Compliance practitioner since 1997.  He is also is a CISSP, CISM, CISA, CEH, and CCFE.

The full proposal can be found here:  Meaningful Use Stage 2 Notice of Proposed Rulemaking

For the purpose of our audience, this blog post will focus only on the security aspects and how they have changed from Stage 1 to Stage 2.  In Meaningful Use Stage 1, healthcare information security is really only addressed in one requirement.  Pondurance has worked with clients to establish compliance with this requirement in their Meaningful Use Stage 1 submission.

The primary goal of security in the Meaningful Use requirement of HITECH/ARRA funding process is to “protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities”.

Meaningful Use Stage 1

Conduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process

 One path for achieving compliance with this measure is to perform a HIPAA security assessment, execute a risk analysis, and develop a plan for remediation of high risk issues.

Meaningful Use Stage 2 (page 82 of the proposal)

Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.

This proposed measure in Stage 2 is nearly the same as in Stage 1 except that encryption/security of data that is stored in the Certified EHR Technology (data at rest) is called out.  The fundamental reason for this is the increasing number of breaches reported to HHS involving lost or stolen devices.

Perhaps the most interesting aspect of this proposed measure is that it really isn’t a new requirement.  It is a focused emphasis of the already existing HIPAA addressable requirement for encryption.  Because ONC and CMS have not recommended changing the existing HIPAA Security requirements to make encryption of ePHI necessary, I think this is their way to move the needle on new technology implementations in healthcare IT.  I expect that this change indicates it will be one of the Stage 2 submission review focus points.  If your Certified EHR doesn’t support encryption, work with your vendor to see when this is available in their future product roadmap.  If it isn’t there soon or if they don’t even want to talk about it, it’s time to start looking at new vendors.  If they offer encryption, but you haven’t implemented it, either ensure your risk assessment formally documents why and what your compensating controls are or get your multi-disciplinary project team engaged now.

In terms of encryption, your ePHI data flow mapping should be able to document the location of ePHI as it is stored, accessed and transmitted.  Ensure you encrypt:

• ePHI in the application database and associated log files (storage)
• any temporary or local storage at the client and don’t forget mobile platforms such as laptops and tablets (access)
• between the client and the application using techniques such as SSL, VPN, or IPsec (transmission)

As a healthcare IT consumer, I am happy to see the renewed focus on encrypting health information and medical data in the proposed changes for Meaningful Use Stage 2.

Steve Lodin is a consultant with Pondurance and has been a CISSP since 1998.

Small and midsize businesses are suffering substantial, sometimes devastating losses to cyberattacks that are becoming increasingly difficult to detect and prevent. While it isn’t yet likely that Advanced Persistent Threats (APTs) target SMBs, they are targets of automated botnets using polished, highly convincing phishing and social engineering techniques, and sophisticated malware that requires no special skills on the part of attackers, thanks to the proliferation of relatively inexpensive malware kits on the criminal market.  SMBs often succumb to the same attacks as individual consumers, but the repercussions are typically far worse: Business as well as personal accounts are compromised; corporate accounts, credit cards and sensitive data are exposed through employees as well as owners; and banks are under no obligation to make good on losses even if a business account is drained of tens of thousands of dollars. Midmarket companies should not feel safe because the big attacks on major companies—Lockhead Martin, Sony, Epsilon, EMC/RSA, Google, Adobe—make the headlines. You may assume your company’s size and obscurity puts it below the radar, but while you may not be singled out for targeting, you may well be a target of opportunity.  There are plenty of stories in the press these days about small businesses, local governments and small healthcare organizations losing money or sensitive customer data.

Many of the cascading technical and process deficiencies at SMBs stem from the fundamental belief that information security and data protection doesn’t matter because their firms are too small to worry about it.  For most small business owners, it is easier to ignore the risk until something happens, then it becomes real.  Breaches and data loss may be caused by external entities such as cybercriminals, competitors, and customers.  However, they can also be caused employees and users.

[Click picture above to open Breach Sources graphic full size]

What are the criminals going after?  For many small businesses, it is company bank-related information, customer credit cards, or personal information.  You know the saying about go where the money is…

[Click picture above to open Data Lost graphic full size]

What can you do about it?

Most information security and data protection efforts can be classified in three distinct techniques along the security lifecycle as prevention, detection, and response.  In terms of large enterprise security, these techniques make up a 3-legged stool.  Ignore one of the legs and that stool (a metaphor for your information security program) will not stand up very well.

Prevent

Prevention is applying techniques in people, process, and technology to prepare the organization eliminate or reduce the risk of an attack occurring or being successful.  The goal of prevention is to minimize your target area.

• Threat and Vulnerability Management (vulnerability scanning, penetration testing, patch management, minimum security baseline configuration)
• Perimeter security tools (firewalls, email security, anti-virus, intrusion prevention)
• User Awareness (education/training, policies, procedures)
• Data Protection (identity and access management, encryption, data leak prevention)

Detect

Detection is being able to accurately and quickly identify that that an attack has occurred while verifying whether it was successful or not.

• Audit Logging (enterprise log collection, analysis and archival)
• Security Information Management (intrusion detection/prevention, event correlation, tuning and optimization)

Respond

Response is the capability to quickly and efficiently address attacks when they are detected.  For the detection process to have any value there must be a timely response.  The organizational response to different incident categories should be planned well in advance.

• Incident Response (policy, procedure, arrangements with a 3^rd party, training, CIRT team development)

Is It Time to Outsource?

A few years ago, many organizations viewed any type of outside security service as taboo. Security operations were considered too private and important to hand off to an outsider, so enterprises continued to hire security specialists and purchase point tools to handle security in-house. But these attitudes are changing—security skills are expensive and hard to find, malware threats are growing in numbers and complexity, and the cost of a data breach can add up to hundreds of millions of dollars. Enterprises are increasingly interested in outsourcing some portion of their security management.  Small businesses can outsource a majority of their security operations, but remember that outsourcing does not completely transfer risk and liability.

In general, security experts agree there are three primary reasons companies decide to outsource security technology to service providers:

• Lack of internal staff and security expertise needed to set up and manage security devices and tools.
• Financially speaking, it is more cost effective to partner with security service providers than investing in on-premise equipment, management, and maintenance fees.
• New levels of sophistication from cybercriminals threaten traditional security methods, and IT managers can benefit from security intelligence services such as those delivered in realtime through SaaS platforms.

You might think your business doesn’t have anything worth stealing but cyber criminals don’t agree. They target small and medium businesses because typically they don’t pay much attention to security. Don’t be a victim, invest in good security now (prevention and detection), before you need it (response).  Pondurance can help develop or improve your information security management program to address all three legs of the stool.

Steve Lodin is a consultant with Pondurance and has been a CISSP since 1998.

While the chief benefactor of the BIA is the enterprise as a whole, the product of the analysis is often limited to certain facets of the organization.  Some astute risk management professionals have seen fit to exploit the harvest of the BIA, but too often its value is relegated to supporting only the traditional facets of business continuity and disaster recovery planning.  For those not familiar with a well-executed BIA, it is essentially a dissection and examination of all components of an enterprise that sustain it (i.e., give it life).  It is certainly not polite to liken a business to a frog in biology class.  However, such an analogy has some merit for this perspective.  Imagine making a symmetrical cut that bilaterally exposes the innards of the frog from under its mouth down to the groin.

I’ll pause briefly in the event that you have passed out… or if you’re taking the time to report me to PETA (I should offer the disclaimer that no animals were actually injured in the writing of this blog).  So with the frog exposed in such manner, it’s rather easy to conclude why you chose risk management over veterinary medicine.  Yuck!  Let’s tune it back to business.

The appropriate analogy to draw from this is that the BIA exposes the systemic and symbiotic processes that give life support to the business.  By breaking down the following (which represents only a sample of collected data), it becomes apparent that the BIA has a purpose that extends far beyond the foundation of a business continuity plan:

• What the organization does (e.g., key business processes)
• How the organization does it (e.g., supporting procedures, applications, infrastructure and data),
• When, and for whom, doing it really matters (e.g., time-based dependencies, critical stakeholders)
• How bad it hurts when they can’t do it, or trust in what they do is damaged (e.g., downtime impacts, privacy or breach impacts, other adverse events)

Imagine if, in the course of collecting this data, one could stretch the process (and it would not be a big stretch at that) to additionally analyze the following:

• The level of classification for supporting datasets (e.g., confidential/private, internal, public)
• The likelihood of threats to processes, systems, etc. which may propagate the occurrence of adverse events (e.g., Threat and Risk Management, Disaster Avoidance, etc.)
• Regulatory concerns with data management (e.g., data flows that illustrate pass-through in addition to intended, and possibly inappropriate, sensitive data handling).
• The impact change has on the operational or technical environments

Executing a BIA is not a light weight effort.  It generally requires vast business and technical representation and participation.  As one might expect with any enterprise effort, the level of quality in the end product is predicated on the level of executive support it receives.  However, the data that is collected in the process is a virtual gold mine that can serve other purposes such as:   Information Security Threats and Risk Analysis; Data Classification and Labeling; Data Flow and Dependency Analysis; Configuration Management and Change Impact Analysis.  It should be noted that there are proven methods to expedite the BIA process, in order to quickly grasp the critical path to sustain business viability.  The merits of expediting the process are almost exclusively for the benefit of establishing and maintaining a business continuity planning program, however, in my opinion.   There is certainly nothing wrong with that approach, but it does tend to limit may be gained from the full traditional effort.

Having executed dozens of BIAs over 14 years as a practitioner, I would submit that the full effort has the potential to reduce the number of similar assessments conducted across the enterprise.  In fact, consolidating such analyses actually provides for not only reduced collective effort, but it can also foster greater collaboration among normally disparate risk management functions.   In my experience, business personnel are not always keen to make time for analyses that they perceive to be redundant, or at least eerily similar in terms of discussion and inquiry.  I would say that most IT personnel are even less inclined to participate in the first place (sorry…but if it aint’ ones and zeros, to them it just ain’t sexy), but they will certainly be reluctant to participate in something they perceive to be a redundant exercise.  It becomes, then, important for risk management functions, even if by committee of risk-relevant organizations such as Enterprise Risk Management, Information Security, Internal Audit, Business Risk Management, and, of course, Business Continuity Management, to streamline the data collection techniques.   So to the naysayers who may claim that such a consolidated effort is tantamount to boiling the ocean, I would say that those claims do not necessarily hold water (pun intended).

And for my new-found scientist fans, the temperature for boiling the ocean is acutely based on the density solution of its salinization, which in turn requires a proportional increase in heat source and temperature that…oh to heck with it, I’ll stick with risk management.

Ron Pelletier is a partner with Pondurance, and he has been a Certified Business Continuity Professional (CBCP) since August of 2000, but a BCP practitioner since 1997.  He is also is a CISSP, CISM, CISA, CEH, and CCFE.

I recently had the pleasure of presenting a 2011 Data Breach Review presentation for the Central Indiana ISSA meeting and it reminded me of a blog post I wrote in 2010 called “The proof is in …We Suck at Information Security”.   I thought it would be a good idea to dust off the old blog post and update it with new data from the Verizon Business 2011 Data Breach report and the Ponemon 2011 Data Breach Cost report.  The interesting thing is nothing has really changed.  A few of the statistics moved a few percentage points up or down but overall the data supports a common theme; most organizations have not implemented a comprehensive information security program which addresses administrative, technical and physical security controls.

96% of breaches were avoidable through simple or intermediate controls*

This means that the breaches are a result of poor patching processes, incorrect configurations, human error or the lack of basic security controls like firewalls and virus software.  Simple security controls and information security “best practices” could have prevented 96% of the breaches that Verizon Business investigated. In my many years of performing security assessments, I have found that companies have no problem spending money on security products but they don’t invest the time and effort in developing information security policies, configuration standards and procedures to insure a secure network environment.

92% of attacks were not considered highly difficult*

This means that it does not take a professional “hacker” with special tools, programming or mad social engineering skills to breach these companies. The attacks used were simple attacks that should have been easily prevented with the proper security controls and administrative procedures. If these companies would have invested in the proper resources and implemented policies, configuration standards, procedures and basic controls, most of these breaches could have been prevented.

86% of breaches were discovered by a third party*

This means that almost no one is effectively monitoring and detecting malicious activities.  From my experience it is usually because of a lack of an effective log-monitoring program. Most of the companies that were breached could have detected the breach or possibly even prevented it if they had just been watching their log files or if they had implemented a log monitoring solution. Companies continue to invest in preventative controls such as firewalls, virus software, NAC and DLP but they don’t want to invest in detective controls such as audit log monitoring solutions.

89% of victims subject to PCI DSS had not achieved compliance*

This proves that the PCI DSS standard is working. I have sometimes been critical of the PCI DSS standard but the implementation of PCI DSS or any other security standard such as HIPAA, GLBA, or SOX will improve information security policies, configuration standards and procedures as well as system and control implementations. Implementing information security “best practices” will address all of the weakness listed above and result in a more secure environment.

63% of the breached companies implemented training and awareness programs after the breach and 54% of the breached companies implemented additional manual procedures and controls**

I believe this statistic supports my theory that the companies included in these surveys did not have comprehensive information security programs implemented at the time of the breach if the corrective action after the breach was administrative changes and additional training.  A proper information security program is about achieving a balance of administrative, technical and physical security controls.

Recommendations

Scary statistics, right? The good news here is all of these breaches could have been prevented. We simply need to implement information security “best practices” and if your company falls under any regulatory compliance areas insure that you implement not only the security controls required but also the policies, configuration standards and procedures. Please understand, building an information security program is not about purchasing the latest security appliance with cool blinking lights.  It is about having the proper resources, policies, configuration standards, procedures and controls to secure your IT environment.

The recommendations I presented during the 2011 Data Breach Review presentation included the following steps to build or improve your information security program:

Administrative Controls

• Improve your Information Security Program
• Update (or create) Policies & Procedures
• Update (or create) Configuration Standards
• Match Configuration Standards to Vulnerabilities
• Develop an Information Security Awareness Program
• Perform Security Awareness Training
• Perform Social Engineering Testing
• Develop a Vulnerability Management Program
• Identify Vulnerabilities
• React to Vulnerabilities
• Patch Vulnerabilities
• Perform Vulnerability Scanning

Detective Controls

• Implement SIEM solution to collect, analyze and alert on suspicious log activity
• Make sure IDS/IPS, AV and DLP logs are monitored
• Perform regularly scheduled Penetration Testing
• Include both Network & Application penetration testing

Preventative Controls

• Closely review firewall rules and implement egress filtering
• Consider implementing DLP or End-Point protection solutions
• Consider implementing Threat / Malware protection solution

To view the entire presentation click here

Sources:

* Verizon Business 2011 Data Breach Report

** Ponemon 2011 Data Breach Cost Report

Presentation by Jeff Foresman from Pondurance at the January 12, 2012 Central Indiana ISSA chapter meeting.

“Those who do not learn from history are doomed to repeat it” – George Santayana

Organizations have a responsibility to protect the data of their customers, employees or other stakeholders. Many organizations are also required to comply with industry requirements or government regulations to protect their confidential data, yet every year hundreds of organizations experience a data breach.

In this attached presentation we review some 2011 data breach statistics and resulting cost estimates, to understand common breach patterns and financial impacts among the affected organizations. We also review the causes of those breaches, and examine possible actions that could have prevented or mitigated the attack.

“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”– Wayne Gretzky

A special thanks to the guest panelists supporting the discussion:

• Dave Sims: WellPoint (Senior Information Security Advisor)
• Tad Stahl: State of Indiana (Chief Information Security Officer)
• Chris Blow: Brightpoint: (Manager, Global Information Security)

Their 34 page report includes survey results and commentary.  It sheds light on five hot topics:

• Key Threats and Mitigation Steps
• Regulatory Compliance Issues
• Technology and Staff Resources
• Cloud Computing Concerns
• Business Continuity Planning

The survey shows improving regulatory compliance efforts ranks as the No. 1 information security priority for the year ahead. And the No. 1 technology investment priority is audit logs.  Mobile security is also a high priority as well.

Download the report here.

One key finding:

- Only 74% of the 175 respondents have completed a HIPAA risk assessment

To help address this issue, Pondurance can facilitate and perform the following for our healthcare clients:

• Perform a HIPAA risk assessment using the Pondurance HIPAA/HITECH security assessment framework.
• Perform application interviews to understand the flow of Electronic Patient Health Information (ePHI).
• Perform interviews of information security, network and systems staff to understand the security controls protecting ePHI.
• Perform technical testing for critical applications to understand the security controls protecting ePHI.
• Perform technical testing of information security, network and systems to understand the security controls protecting ePHI.
• Perform management interviews in Information Technology, Information Security, Physical Security, HR, Disaster Recovery and Media Handling.
• Document findings in the Pondurance HIPAA/HITECH assessment report showing risk level, gaps in the HIPAA/HITECH security requirements and recommendations for remediation.
• Create an Executive Summary document and PowerPoint presentation summarizing the findings and recommendations.
• Provide our clients with general HIPAA/HITECH guidance and advice on their Meaningful Use application.

Furthermore, we can review PHI applications thoroughly from the perspective of source code and provide understanding of pertinent areas of the applications through threat modeling.

If you are in the 26% who haven’t yet done their HIPAA risk assessment, please contact us for a discussion on the topic.

Enterprise Security Vulnerability Management – Quick Wins and Gotchas

Implementing and executing an enterprise security vulnerability management program requires both time and/or money to be successful. This last part of the Enterprise Security Vulnerability Management series describes a couple of quick wins and some gotchas to look out for while dedicating your time or money.

It doesn’t have to be expensive

But, here is the caveat to that claim – the less you spend on your “enterprise” vulnerability management system, the less functionality in “management” features you get in the solution.  For a relatively cheap price, an enterprise can implement a vulnerability scanner such as Nessus with their Professional feed.  However, the reporting and data management features are really not “enterprise” solution capable.  This is where the tradeoff between money and resources really plays out – you pay less money, but it requires more work to create those reports and manage the data.

As an alternative to dedicating 25-50% of a full-time resource to operate your enterprise vulnerability management program, purchase vulnerability management as a service.  VM as a service should offer weekly threat and vulnerability analysis, monthly internal vulnerability scans, and quarterly external vulnerability scans.  The ongoing care and feeding of the vulnerability scanning solution is outsourced.  Some solutions only provide scan results in a dashboard, others spend time on site working with you to understand and remediate the identified vulnerabilities. Pick whatever works best in your situation.

Mine your own data

If you aren’t happy with the quality of the default reports in Nessus and you can’t afford the Tenable SecurityCenter data management, analysis, reporting and alerting tool, there might be some free tools that can help.  Again, it is the tradeoff between money and resources.  Three potential vulnerability data management tools are listed below.  The evaluation of these tools will be available in a future blog entry.

Risu (formerly known as NessusDB) from Jacob Hammack

• Risu is an open-source Ruby-based Nessus parser, that converts the generated reports into an ActiveRecord database, this allows for easy report generation and vulnerability verification.
• Risu requires a Ruby environment and a database such as MySQL or SQLite.  It can run on Windows and Linux.

MagicTree from Gremwell

• MagicTree is a closed-source Java penetration tester productivity tool. It is designed to allow easy and straightforward data consolidation, querying, external command execution and report generation. In case you wonder, “Tree” is because all the data is stored in a tree structure, and “Magic” is because it is designed to magically do the most cumbersome and boring part of penetration testing – data management and reporting.
• MagicTree is a Java client application that can run on Windows and Linux.

Dradis from Security Roots

• Dradis is an open source framework to enable effective information sharing, especially during security assessments.
• Dradis is a self-contained web application that provides a centralized repository of information to keep track of what has been done so far, and what is still ahead.  The Dradis server requires Ruby and SQLite and runs on Unix-like systems – installation guides for BackTrack, Ubuntu, FreeBSD and OSX are available.

Dig deeper

The quality of your enterprise vulnerability management program is highly dependent on the data it is based on.  The amount and quality of the data can be enhanced by two factors:

1)      Use more network and application vulnerability scanning tools.  This provides greater breadth in the vulnerabilities tested and can also provide corroboration in the findings.

You can always try security vulnerability testing tools on LiveCD distributions such as BackTrack, the Network Security Toolkit (NST), or the Security Tools Distribution (STD).  I recommend limiting your testing to systems in your designated test / development network prior to testing production systems.  The results from these tools could supplement or confirm the results from your regular vulnerability scanner.

2)      Don’t rely on network-only vulnerability scans.  Configure your vulnerability scanner with credentials.  Credentialed scans produce much better results regarding patching status and local host security configuration items that aren’t generally available from a network-only vulnerability scan.

However, even with credentialed scans, don’t believe you are scanning for “every” vulnerability out there.  Credentialed scanning allows the vulnerability scanner to log in to the target and determine application version information using meta-information from the Windows registry or other package management databases. This allows the scanners to be much more accurate and also provides much greater coverage than an unauthenticated scan. Using this local information, a credentialed scan can determine specific versions of libraries being used or versions of client software that have no listening services, among other granular security checks that can only be performed using credentials.  But even then, only approximately 25% of reported vulnerabilities make it into the signature database of vulnerability scanners.

3)     If time and resource skill-sets are on your side, leverage manual penetration testing to identify issues and vulnerabilities within your environment. Typically targeted towards your application stack, this can vary from source code analysis, application architecture reviews, threat modeling, business logic analysis, database schema and permission analysis, to automated database configuration reviews.

Don’t trust, verify

The “trust, but verify” signature phrase of Ronald Reagan doesn’t really apply to vulnerabilities scanners.  Inevitably, some reported vulnerabilities are false positives.  A false positive is when you think you have a specific vulnerability in your system or application but in fact you don’t.  You might consider running a second, more specialized security testing tool to test the vulnerability finding.  Tracking these down can be a hassle, but don’t blindly assume that because the vulnerability scanner identified a vulnerability, that it actually exists.

For instance many Linux-based operating systems leverage backporting which increases the number of false positives as many vulnerability scanners rely upon version numbers in requests. To “verify” that there are outstanding patches, you will need to get the output from the relevant system. On a RHEL based system (CentOS, Fedora, etc) the “yum list available ‘httpd*’” would provide output for any available Apache httpd patches that need to be installed. To list all of the currently installed patches on the same type of systems you can simply review the list of installed packages “rpm -qa|grep httpd” and manually compare them to the relevant Linux distribution errata.

As another example, the OS detection function of vulnerability scanners is not 100% accurate.  While you may be able to find some weird system types on your network, don’t assume that the OS detection function of vulnerability scanners is infallible, they might not be what they look like.   To help validate, look at all the headers retrieved in service detection plug-ins.  Try running NMAP or telneting to the open ports to see what is returned.  Verify.

Address the core problem early

If you want to make your job easier in minimizing the results from your enterprise vulnerability scan, work to eliminate the problems before they occur.  Here are four ideas:

1)      In your IT Standard Project Development Methodology or System Go-live Checklist, make sure there is a required vulnerability scan, with allowed remediation time prior to go-live approval.

2)      This is kind of like closing the barn door after all the horse have left, but make sure that there is an owner for each new system and application. Confirm that they know what their responsibilities are regarding on-going maintenance and patching.  Anytime you review a project implementation plan and do not see an operational process in the maintenance phase for patching, do not approve.

3)      Develop an active threat and vulnerability intelligence process identifying vulnerabilities and providing remediation steps that can be implemented prior to the vulnerability scanner pointing out the problems.  This requires a philosophical shift from reactive (don’t touch it unless it is broken) to proactive (preventative maintenance planning).

4)      Implementing well-defined Minimum Security Baselines (MSBs) as part of the system build procedure will eliminate some of the meticulous items like default accounts/passwords, incorrect SSL version, weak ciphers, and other easily fixed vulnerabilities. If you scour the Internet, there are many available publicly or you can leverage guidelines offered by NIST, CIS, NSA, or Tenable (Nessus .audit policies).

This ends our 3 part series on Enterprise Security Vulnerability Management.  If you are struggling with your current enterprise security vulnerability management program, or if you need to implement one, contact us at Pondurance for assistance.