Threat and Vulnerability Management

Threat and Vulnerability Management

The best way to ensure a fighting chance of discovering and defeating information exploitation and theft is to take a disciplined, programmatic approach to discovering and mitigating threats and vulnerabilities. Threat and Vulnerability Management is the cyclical practice of identifying, assessing, classifying, remediating, and mitigating security weaknesses together with fully understanding root cause analysis to address potential flaws in policy, process and, standards – such as configuration standards.

Vulnerability assessment and management is an essential piece for managing overall IT risk, because:

• Persistent Threats –
  • Attacks exploiting security vulnerabilities for financial gain and criminal agendas continue to dominate headlines.
• Regulation –
  • Many government and industry regulations, such as HIPAA-HITECH, PCI DSS V2 and Sarbanes-Oxley (SOX), mandate rigorous vulnerability management practices
• Risk Management –
  • Mature organizations treat it as a key risk management component.
  • Organizations that follow mature IT security principles understand the importance of risk management.

Properly planned and implemented threat and vulnerability management programs represent a key element in an organization’s information security program, providing an approach to risk and threat mitigation that is proactive and business-aligned, not just reactive and technology-focused. Threat and vulnerability management programs include the following 4 major elements:

• Baseline
• Assess
• Remediate
• Lifecycle Management

Each of these elements individually benefits the organization in many ways, but together they form interlocking parts of an integrated, effective threat and vulnerability management program.

Baseline

Policy

The threat and vulnerability management life cycle begins with the definition of policies, standards and specifications that define access restrictions, and includes configuration settings that harden the IT infrastructure against external or internal threats. Security configuration policies and specifications should be based on industry-recognized best practices such as the Center for Internet Security (CIS) benchmarks or National Institute of Standards and Technology (NIST) recommendations.

The development of security configuration policies and specifications is an iterative process that starts with industry standards and best practices as a desired state. However, many organizations may also need to define exceptions in order to accommodate specific applications or administrative processes within their environment and track them for resolution.

Organizations should also consider a mapping of organization-specific configuration policies and operational processes to industry-recognized control frameworks and best practices. Organizations that take the extra step of mapping the policies that are implemented by vulnerability management to control standards and best practices can strengthen their posture with auditors and reduce the cost of compliance reporting through automation. The mapping enables compliance reporting from configuration assessments.

Asset Inventory

To protect information, it is essential to know where it resides. The asset inventory must include the physical and logical elements of the information infrastructure. It should include the location, business processes, data classification, and identified threats and risks for each element.

This inventory should also include the key criteria of the information that needs to be protected, such as the type of information being inventoried, classification for the information and any other critical data points the organization has identified. From this baseline inventory pertinent applications and systems can be identified to iteratively develop and update an Application Security Profile Catalog. It is important to begin to understand application roles and relationships (data flows, interfaces) for threat and risk analysis since a set of applications may provide a service or business function. This will be discussed in more detail in a future blog.

Service Dependency Mapping

Classification of assets according to the business processes that they support is a crucial element of the risk assessment that is used to prioritize remediation activities. Assets should be classified based on the applications they support, the data that is stored and their role in delivering crucial business services. The resource mapping and configuration management initiatives within the IT operations areas can begin to provide the IT resource and business process linkage that is needed for security risk assessment.

IT operational areas need service dependency maps for change impact analysis, to evaluate the business impact of an outage, and to implement and manage SLAs with business context. IT operations owns and maintains the asset groupings and asset repositories needed to support service dependency mappings.

This information is typically stored in an enterprise directory, asset management system or a CMDB. Further details will be provided in the forthcoming Application Architecture Taxonomy blog.

The security resource needs the same information in order to include business context in the risk assessment of vulnerabilities, to prioritize security incidents, to publish security metrics with business context and to publish compliance reports that are focused on the assets that are in scope for specific regulations.

Security resources should engage IT application operations areas to determine the sources for IT service dependency maps and should configure security assessment functions to dynamically access or import this data for risk analysis, security monitoring and compliance reporting functions. The security team should also participate in CMDB projects as a stakeholder and supporter.

Configuration Standards by Device Role

A vulnerability management program focusing only on vulnerability assessment is weak regarding a crucial vulnerability management program objective — making the environment more secure. Although vulnerability assessment excels at discovering security weaknesses, its reporting isn’t optimized for the mitigation work performed by operations areas. Chasing individual vulnerabilities often does not eliminate the root cause of the problem. A large percentage of vulnerabilities results from underlying configuration issues (missing patches, ports that shouldn’t be open or services that shouldn’t be running).

The security resource should work with IT operations to define security configuration standards, and should use the security configuration assessment capability within their incumbent vulnerability assessment tool (if the vulnerability assessment tool provides it) to drive implementation of security configuration standards in desktop, network and server provisioning processes.

Threat and Vulnerability Analysis

To perform threat analysis effectively, it is important to employ a consistent methodology that examines the business and technical threats to an application or service. Adversaries use a combination of skills and techniques to exploit and compromise a business process or application, so it is necessary to have in place a similarly multipronged approach to defend against them that decomposes and analyzes systems.

Vulnerability Assessment

The next step is to assess the environment for known vulnerabilities, and to assess IT components using the security configuration policies (by device role) that have been defined for the environment. This is accomplished through scheduled vulnerability and configuration assessments of the environment.

Network-based vulnerability assessment (VA) has been the primary method employed to baseline networks, servers and hosts. The primary strength of VA is breadth of coverage. Thorough and accurate vulnerability assessments can be accomplished for managed systems via credentialed access. Unmanaged systems can be discovered and a basic assessment can be completed. The ability to evaluate databases and Web applications for security weaknesses is crucial, considering the rise of attacks that target these components.

Database scanners check database configuration and properties to verify whether they comply with database security best practices.

Web application scanners test an application’s logic for “abuse” cases that can break or exploit the application. Additional tools can be leveraged to perform more in-depth testing and analysis.

All three scanning technologies (network, application and database) assess a different class of security weaknesses, and most organizations need to implement all three.

Risk Assessment

Larger issues should be expressed in the language of risk (e.g., ISO 27005), specifically expressing impact in terms of business impact. The business case for any remedial action should incorporate considerations relating to the reduction of risk and compliance with policy. This incorporates the basis of the action to be agreed on between the relevant line of business and the security team

“Fixing” the issue may involve acceptance of the risk, shifting of the risk to another party or reducing the risk by applying remedial action, which could be anything from a configuration change to implementing a new infrastructure (e.g., data loss prevention, firewalls, host intrusion prevention software).

Elimination of the root cause of security weaknesses may require changes to user administration and system provisioning processes. Many processes and often several teams may come into play (e.g., configuration management, change management, patch management). Monitoring and incident management processes are also required to maintain the environment.

For more details on threat and risk assessment best-practices see the blogs: Risk-Aware Security Architecture as well as Risk Assessment and Roadmap.

Vulnerability Enumeration

CVE – Common Vulnerabilities and Exposures

Common Vulnerabilities and Exposures (CVE®) is a dictionary of common names (i.e., CVE Identifiers) for publicly known information security vulnerabilities. CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools. If a report from one of your security tools incorporates CVE Identifiers, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem.

CVSS – Common Vulnerability Scoring System

The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. Its quantitative model ensures repeatable accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the scores. Thus, CVSS is well suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability impact scores.

CWE – Common Weakness Enumeration

The Common Weakness Enumeration Specification (CWE) provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. Each individual CWE represents a single vulnerability type. CWEs are used as a classification mechanism that differentiates CVEs by the type of vulnerability they represent. For more details see: Common Weakness Enumeration.

Remediation Planning

Prioritization

Vulnerability and security configuration assessments typically generate very long remediation work lists, and this remediation work needs to be prioritized. When organizations initially implement vulnerability assessment and security configuration baselines, they typically discover that a large number of systems contain multiple vulnerabilities and security configuration errors. There is typically more mitigation work to do than the resources available to accomplish it.

The organization should implement a process to prioritize the mitigation of vulnerabilities discovered through vulnerability assessments and security configuration audits, and to prioritize the responses to security events. The prioritization should be based on an assessment of risk to the business. Four variables should be evaluated when prioritizing remediation and mitigation activities:

• Exploit Impact  – the nature of the vulnerability and the level of access achieved.
• Exploit Likelihood – the likelihood that the vulnerability will be exploited.
• Mitigating Controls – the ability to shield the vulnerable asset from the exploit.
• Asset Criticality – the business use of the application or data that is associated with the vulnerable infrastructure or application.

Remediation

Security is improved only when mitigation activity is executed as a result of the baseline and monitoring functions. Remediation is facilitated through cross-organizational processes and workflow (trouble tickets). Although the vulnerability management process is security-focused, the majority of mitigation activities are carried out by the organization’s IT operations areas as part of the configuration and change management processes.

Separation of duties dictate that security teams should be responsible for policy development and assessment of the environment, but should not be responsible for resolving the vulnerable or noncompliant conditions. Information sharing between security and operations teams is crucial to properly use baseline and monitoring information to drive remediation activities.

For more details on remediation planning and execution see complementary blog: Vulnerability Assessment Remediation

Vulnerability Lifecycle Management

Vulnerability management uses the input from the threat and vulnerability analysis to mitigate the risk that has been posed by the identified threats and vulnerabilities. A vulnerability management program consists of a continuous process, a lifecycle as follows:

Monitor Baseline

While a threat and vulnerability management program can make an IT environment less susceptible to an attack, assessment and mitigation cannot completely protect the environment. It is not possible to immediately patch every system or eliminate every application weakness. Even if this were possible, users would still do things that allowed malicious code on systems.

In addition, zero-day attacks can occur without warning. Since perfect defenses are not practical or achievable, organizations should augment vulnerability management and shielding with more-effective monitoring. Targeted attacks take time to execute, and the longer a breach goes unnoticed, the greater the damage. Better monitoring is needed to detect targeted attacks in the early stages, before the final goals of the attack are achieved. Use security information and event management (SIEM) technologies or services to monitor, correlate and analyze activity across a wide range of systems and applications for conditions that might be early indicators of a security breach.

Root Cause Analysis

It is important to analyze security and vulnerability assessments in order to determine the root cause. In many cases, the root cause of a set of vulnerabilities lies within the provisioning, administration and maintenance processes of IT operations or within their development or the procurement processes of applications. Elimination of the root cause of security weaknesses may require changes to user administration and system provisioning processes.

Conclusion

In 2012, less than half of all vulnerabilities were easily exploitable, down from approximately 95 percent in 2000. In addition, fewer high severity flaws were found. The number of vulnerabilities with a score on the Common Vulnerability Scoring System (CVSS) of 7.0 or higher dropped to 34 percent of reported issues in 2012, down from a high of 51 percent in 2008.

Unfortunately, there are more than enough highly critical flaws to go around. In 2012, more than 9 percent of the publicly reported vulnerabilities had both a CVSS score of 9.9 and a low attack complexity, according to NSS Labs. Vulnerabilities disclosed in 2012 affected over 2,600 products from 1,330 vendors. New vendors who had not had a vulnerability disclosure accounted for 30% of the total vulnerabilities disclosed in 2012. While recurring vendors may still represent the bulk of vulnerabilities reported, research shows that the vulnerability and threat landscape continues to be highly dynamic.

Thanks for your interest!

Nige the Security Guy.

Vulnerability Assessment Remediation

Vulnerability Assessment Remediation

The external threat environment has become quieter and much more dangerous. Today’s attacks target specific companies, individuals and data. A typical targeted attack will exploit multiple security weaknesses to achieve the ultimate goal — usually, to steal sensitive data, compromise a specific account or disrupt operations.

Organizations need to present a hardened defensible target to an attacker in addition to the ability to detect and contain. This requires a combination of vulnerability assessment and management processes to find and fix security weaknesses in systems and applications, and the implementation of compensating controls or shielding technologies to protect more legacy systems and applications that will have long-standing vulnerabilities.

In the Security Assessment Series this blog discusses more tactical and reactive vulnerability assessment and remediation while the next blog in the series will cover strategic and more proactive vulnerability and risk management.

Vulnerability Assessment versus Penetration Tests

Over 25 years I have performed hundreds and hundreds of security assessments for organizations, many of those have been vulnerability assessments and penetration tests. In my experience many organizations seek a penetration test when they really need to perform a vulnerability assessment and address those issues before progressing onto a penetration test. I am often asked to perform a penetration test yet discover the environment is not hardened and suffers from many basic flaws. While a penetration test sounds exciting there are key differences.

A Vulnerability Assessment is designed to allow an organization to identify all of the potential vulnerabilities, validate them, prioritize them based on scores, such as the Common Vulnerability Scoring System (CVSS) for all CVE vulnerabilities (provided by the National Vulnerability Database) and, create a prioritized list for remediation. The scope is broad across many external and/or internal systems. Root cause analysis may be warranted to understand why the vulnerabilities exist and what processes need addressing to resolve fully. These are more tool-based tasks and seek to identify as many potential issues as possible.

Vulnerability assessments typically follow these general steps:

1. Catalog assets and resources in a system
2. Assign value and importance to the resources
3. Identify vulnerabilities or potential threats
4. Mitigate or eliminate most serious vulnerabilities

A Penetration Test is either focused on a hardened and locked down environment or a specific platform or service that an organization wants validation to ensure nothing was missed or if there is a yet un-discovered flaw or vulnerability. They are often used as a pre-production validation for sensitive systems or to assess what can be achieved with a mix of advanced threats and social engineering. These leverage more manual methods and will report out on the path the attacker took and the creative exploits used to ‘capture the flag’.

Penetration tests typically follow these steps:

1. Determination of scope and target(s)
2. Information gathering or reconnaissance
3. Exploitation attempts for access and escalation
4. Sensitive data collection and ex-filtration testing
5. Clean up, evidence collection and reporting

As part of an emerging and evolving network security program organizations should deploy a vulnerability assessment and phased remediation strategy that makes practical sense to address the current and tactical vulnerability landscape and, in parallel evolve that towards a more comprehensive and proactive vulnerability and risk management strategy.

Vulnerability Landscape

During a vulnerability assessment it is possible to discover many vulnerabilities and the sheer volume of data can quickly become overwhelming. This blog proposes a practical and simplified process to get you started, focused on asset inventory and classification to profile the vulnerabilities and thus enable the appropriate prioritization and scheduling of remediation actions.

Inventory

Taking a complete inventory of the basic makeup of the organization’s network is a critical first step. The second thing is to actually inventory all the mission critical and/or enterprise applications being used. I typically recommend that an Asset Inventory is developed that contains a list of all of the approved assets, services, interfaces, connections and, so on. While this may not be possible in all cases it is extremely important for external accessible services as well as mission critical or core services. This will be covered more fully in a future blog on Application Architecture Taxonomy.

• Inventory –
  • Inventory Network Infrastructure
  • Inventory Applications and Services
    • Identify Device Roles/Groups
    • Service Dependency Mapping
      • Organization Function
      • Service Group
        • Applications
        • Ports
        • Relationships

Classification Asset classification, based on criticality and sensitivity enables the determination and priority of the application of security configuration standards and remediation actions. For example, assets that are in production should conform to all of the applicable security standards as part of deployment and maintenance and critical and/or sensitive assets are prioritized. A future blog will take a deep-dive into data classification.

• Classification –
  • Category –
    • R&D
    • Staging
    • Production
    • Mission Critical
  • Classification –
    • Restricted
    • Trusted
    • Internal
    • Public

Identification

Ideally, the identification phase should occur during the architecture and design phase (e.g., via security sign-off criteria), immediately prior to the equipment becoming operational (e.g., as a step in the release management process), and at regular intervals throughout the operational life of the infrastructure. Identification and, to some extent, assessment come from activities such as vulnerability scanning and penetration testing – of which this blog provides a foundation and an opportunity to develop a practical methodology and process.

Assessment

Assessment requires knowledge of the technical implications of the weakness, and also of the business implications of the exploitation of the weakness. The risk owner must then make a decision regarding acceptance of the risk, remedial action to fix the weakness or transformation of the risk into another form.

• Assessment –
  • Evaluate Vulnerability Risk
    • Accept
    • Avoid
    • Mitigate
    • Transfer

It is a normal practice to rationalize a set of reported vulnerabilities into groups that are accepted but documented, those that have mitigating controls and, those that are mitigated with a solution.

Remediation

Remediation may range from detailed bottom-up technical measures, such as the application of patches, or changes to the configuration of firewalls or other network-based vulnerability protection infrastructure, through changes to custom-made applications, right up to very high-level measures, such as changes to governing policy, processes and procedures or configuration standards.

• Remediation –
  • Create Remediation Task Map
    • Action Plan:
      • Budget
      • Resources
      • Priority
      • Timing
        • Immediate
        • 30 Days
        • 6 Months
        • Future
    • Typical Actions:
      • Patch
      • Upgrade
      • Configuration Standards Rollout [by Role]
      • Infrastructure Refresh
      • New Deployment

Reporting

Reporting metrics should include frequency of identification exercises (e.g., regular vulnerability reports), and results from identification and assessment, including the number of issues and accumulated risks, and the tracking of remediation actions. In a future blog we will expand this to include the use of a risk register and tracking in the Risk Management blog to report upwards to executive management.

• Reporting –
  • Metrics and Trends:
    • Number of issues
    • Accumulated risks
    • Tracking remediation actions

The next blog in the Security Assessment Series will develop this theme further to cover more proactive Vulnerability Management Strategy. Once the organization becomes more secure it can evolve to stay more secure.

Thanks for your interest!

Nige the Security Guy.

Product and Solution Selection

Product and Solution Selection

The security architecture and migration strategy (which now embodies your approved and prioritized requirements) may recommend specific products, or it may recommend going through a competitive process to select products. In either case, partner selection isn’t final until costs and schedules are nailed down, funding approved, and contracts signed.

The architecture is an important foundation for selecting the right vendors, partners, and approaches. However, additional tools are required during product evaluation and procurement. Relatively informal Requests for Information (RFIs) can bring the team up to speed on the advantages and disadvantages of various products. Formal requests for proposals (RFPs) should form the final basis for vendor selection and tasking.

First, based on your security architecture, arrive at a short list of vendors or partners for further consideration. Because the architecture covers a number of different functional areas, no one supplier will be able to provide the full solution. However, within each zone (Trusted, Restricted, DMZ, Management, Audit) use the fewest possible number of vendors and try to maximize the integration between those vendors. Also consider what tools and standards you’ll need to integrate across layers (e.g., provisioning as a Management Zone tool that works with the other zones).

Next, complete any information gathering necessary to make a decision as well as obtain and evaluate formal proposals from vendors. Finally, select vendors and partners and obtain funding to proceed with the project.

Develop Shortlist of Vendors and Partners

Developing a vendor shortlist is your first step in selecting architecture solutions. By narrowing the universe of product choices down to a few (perhaps between one and four), the shortlist helps focus time and energy on the most likely solutions. Developing a short list of vendors and partners can be complex. You may want to look at a different, though overlapping, set of vendors for internally hosted, co-sourced and/or externally managed purposes.

Develop Security RFI/RFPS, Evaluate, and Select

During the RFI/RFP process, you must decide on a procurement approach, hire or task procurement support resources, define evaluation criteria, develop procurement documents, hold an RFI/RFP workshop with each bidder to clarify technical architecture and process, and evaluate proposals from bidders.

Depending on how you’ve layered your architecture, you may need to conduct multiple RFI/RFP processes to acquire the specified security infrastructure. For example, in our generic security architecture model, you might issue an RFP for the Identity and Access Management functions, and another for Network Perimeter functions.

Thus, how many RFI/RFP procurement processes you require depend on how you’ve layered your architecture, the functional groups and what integration points you have defined. It could also depend on whether your team favors relying on a single System Integrator tasked to provide a whole solution, versus working with multiple vendors individually (best-of-breed). The following discussion, therefore, pertains to managing one, or multiple, RFI/RFP processes.

Defining the Procurement Approach

If your vendor shortlist has more than one vendor listed, then you will need a competitive RFI/RFP process to select a supplier. Even if a single security solution supplier has been selected for a particular requirements set, you may want to request a formal proposal prior to signing an order.

It is up to you to decide how formal the process of selecting the supplier should be. There are advantages and disadvantages to having a “heavy” RFI/RFP process. A lightweight process with fewer steps and fewer demands on the vendor and on your proposal review team can move faster. A heavy process requesting a great deal of information and proof points for vendors takes longer but also increases your certainty that you have chosen the right solution and may also result in more competitive pricing.

Hiring/Tasking Procurement Support Resources

In almost all cases, we recommend that customers do their own evaluation of the security information and proposals they receive in response to their RFI or RFP. Letting vendors or system integrators define the entire solution and tasking for you without any review is like letting a fox into the henhouse. Use your own staff and/or a vendor-independent consultant to help evaluate proposed solutions and tasking.

Developing RFPs

A competitive RFP process tests the vendor’s mettle and drives down the price. It gives you a chance to get comfortable with the account team and the consultants from the vendor(s). But if you commit to the competitive process, be prepared to spend some time and money on that process. Don’t push out a half-baked RFP that’s cut and pasted from the architecture and your contract boilerplate. Instead, make sure it’s a good RFP that defines a level playing field for vendor evaluation. Request the right information in the right way.

The architecture forms the backbone of the RFP by defining technical specifications and definitions for security services (such as dynamic roles) and additional capabilities (such as rules-based services). This helps you put the vendor’s differentiated product marketing “fluff” into a common technical framework. But the RFP must also tell the vendors what your evaluation criteria really are and provide instructions to the vendor on how to respond. You need to get answers from the vendors in a form that lets you compare apples to apples and oranges to oranges.

RFP Workshop and Evaluation

Don’t judge proposals by their weight alone. Depending upon the scope of the requirements, you may want to give a hard page limit. Don’t just throw the documents over the wall. Give the vendor enough time to respond. Also, for large complex systems such as identity management solutions, we strongly recommend that you have an in-depth, in-person RFP workshop meeting with each bidder and that you bring your professional advisors to this workshop.

The RFP workshop is important because it gives the vendor a chance to learn more about your environment and goals. It gives you a chance to get to know the vendor’s key technical people. Also, you’ll learn a lot more about the vendor’s product and solution-development approach, and you’ll get some high-level design work done up front. After the workshop, you can and should expect a much more specific, tailored proposal from the vendor than you would otherwise have received. After all, you don’t want to review a proposal offering no more than a marketing spiel and/or a phony, cut and paste “solution.” Rather, you want a well-thought out proposal for a real solution that’s tailored to your environment.

Evaluating the Proposals

After the proposals are in and the workshops have been held, roll up your sleeves and analyze each proposal. During the RFP development process you should have identified the evaluation criteria to be used. Create an RFP summary matrix to compare the responses and prioritize key functional requirements. Be very open with team members; avoid hidden agendas. Use your IT Architecture Principles (discussed earlier under architecture) to get intangible considerations (such as preferences for best-of-breed vs. single vendor products, mature vs. leading-edge technology, or existing relationships with a particular partner) out on the table. These considerations need to become part of the weighted set of factors going into making a decision.

Security Solution Bake-Off

A network security product or solution bakeoff is an important step in the RFI/RFP evaluation, negotiation, and planning process because it offers the best way to understand the real capabilities and performance of the devices you are considering. As we all know, a bit of preparation on the front end is always required to get accurate results. Combine that with insider knowledge and you can ensure an accurate and deterministic network device evaluation.

The following graphic depicts an example of a methodology that was used to test across Firewall, IPS, VPN and Management solutions driven by real-world penetration testing mapped to validating RFI requirements for Detection, Response, Alert/Logging, Correlation, Reporting, and so on.

Obtain Funding Approval to Execute Strategy

Now that the final proposal(s) are in and the best solutions have been selected, you’ll be asking for the first time for serious money. If expectations were built correctly at the beginning of the process, then the price tag may not come as a big surprise. On the other hand, this is where the rubber meets the road, and you may once again be questioned about the value of the security project. In fact, you may feel that selling security is a forever process— it is. Security is part diplomacy, part salesmanship and, part the art of integration to build a holistic system.

Thanks for your interest!

Nige the Security Guy.

Risk Assessment and Roadmap

Risk Assessment & Security Roadmap

With benchmarking data collected from the Security Health Check – Snapshot Assessment task it is time to chart a course. Strategic planning must focus on relevant, practical, and proportional recommendations. This Risk Assessment and Security Roadmap blog can enable organizations to:

Establish Coordinates –

• Pinpoint your Business Requirements
• Create your Security Risk Profile

Harmonize –

• Integrate Regulatory, Legal and, Policy Drivers
• Identify Organization Stakeholders and Seek Consensus

Chart your Course –

• Develop a Security Roadmap
• Deliver Prioritized Action Plans

The Need for a Solid Risk Assessment Program

Meeting today’s numerous information security regulations is one of the most challenging and complex issues facing corporate IT today. The increased frequency of security incidents, including well publicized breaches, has resulted in new legislation at both the federal and state level.

Fundamental to meeting these regulations, including the Gramm-Leach-Bliley Act (GLBA), the Health Insurance Portability and Accountability Act (HIPAA) and Sarbanes-Oxley are regularly scheduled risk assessments. Each of these regulations holds organizations accountable for the protection of private information and requires risk assessments as one component of an effective security program.

Now, more than ever, organizations need a complete understanding of the impact of regulations on their core business and the need for third party risk assessments to comply with these regulations.

When harmonized with security policy the most fiscally responsible and secure infrastructure is driven from the top with clear strategic justification, prioritization, and timing.

The first step in developing a proactive IT Security Governance program is the risk assessment. The risk assessment identifies and prioritizes risks to enterprises via networks and information systems. Risk assessment is the foundation for developing risk management strategies within an organization. Organizations should use a practical methodology which identifies the assets that support business operations, the vulnerabilities, and the threats to those assets.

Risk is present at the union of:

• Assets,
• Threats,
• Vulnerabilities

Our methodology consists of information gathering to determine the current state, analysis of information, and the development of a security roadmap

Information Gathering

The information gathering process focuses on the three key risk components: assets, vulnerabilities, and threats. The approach is asset-centric, meaning the risk assessment begins with the identification of assets and the value/criticality of assets that are central to business operations. Threats which could impact these assets are identified and assessed. Finally, vulnerabilities that may be present on the asset controls are examined to determine the likelihood of impact.

The information gathering phase typically consists of interviews with business managers and technical staff and review of documentation relating to information security and assets (including network topology). Technical vulnerability assessment results can be used to enhance the accuracy of initial risk assessment results, leveraging Common Vulnerabilities & Exposure CVE) together with the Common Vulnerability Scoring System (CVSS).

Asset Identification

The goal of a risk assessment is to identify the risk to critical business operations. The first step in the risk assessment is to identify the assets that support critical business operations. These assets could include physical and logical assets such as data center systems, employee computers, network communications devices and channels, remote work areas such as employee’s home computers, customer data, employee data, and intellectual property.

The key critical and sensitive assets that support business areas are identified through documentation review and interviews of business managers and select technical staff, identifying:

• Physical assets and locations
• Asset ownership and classification
• Network and logical connectivity
• Software (OS and application)
• Data flow throughout the network

Questions during the interview also focus on how the information technology assets are utilized by all types of system users – administrators, customers, employees, etc. This allows a profile to be built of Application Roles and Relationships and User Roles and Relationships. Assets are then ranked based on their value to operations.

On a scale of 1 to 4, asset value will be ranked as follows:

1. Catastrophic – catastrophic failure is possible if the asset is destroyed / compromised.
2. Critical – the asset is considered “mission critical” to business operations.
3. Marginal – the asset marginally affects business operations; some degradation of service is likely if the asset is destroyed / compromised.
4. Negligible – destruction / compromise of the asset will have a negligible effect on business operations.

Vulnerability Assessment

Threats cannot impact assets unless the assets are vulnerable to the specific threats. Security mitigating controls may be in place, reducing the likelihood of a threat exploiting a given asset. Understanding the types of vulnerabilities that exist on critical assets is a key step in the risk assessment.

Comprehensive information security programs require that every asset have protective measures in the areas of:

• Protection
• Detection
• Containment
• Eradication
• Recovery

Preventative measures reduce the likelihood of exploitation. The ability to detect and respond to incidents allows an organization to minimize losses in the event of exploitation. Furthermore, effective detection and response provides a deterrent to exploitation attempts.

Vulnerabilities can be identified based upon the degree of protective measures in the areas of prevention, detection, and response. For each critical asset, identify the status of compensating or mitigating controls in place. A few examples of areas to evaluate include:

Prevention

• Security policies and procedures
• Network and application architecture
• Software version and patch level
• Network segmentation and access controls
• Authentication/authorization mechanisms
• Security awareness program

Detection

• Network intrusion detection capabilities
• Host intrusion detection capabilities
• Incident reporting policy and processes

Response

• Incident response program capabilities
• Response policies and process
• System back-up and recovery capabilities

Vulnerabilities that affect critical assets are discovered through interviews, documentation review, and technical analysis and validation testing. Vulnerabilities are classified based on their severity. Severity identifies the exposure of an asset:

• High – vulnerability which allows threat to control/destroy an asset.
• Medium – vulnerability which allows threat to compromise/access an asset.
• Low – vulnerability which provides threat information which could be used to compromise an asset.

For each critical asset identified during the asset identification phase, identified vulnerabilities are noted and classified.

The more accurate the vulnerability assessment, the more accurate the risk assessment will be. The assets and threats that support and impact business operations tend to change much less frequently than the vulnerability analysis. New vulnerabilities, changes in technology, and user/administrator introduced issues all contribute to a dynamic vulnerability environment. Areas identified through this high level vulnerability assessment are candidates for a detailed, technical assessment.

Threat Identification

Threats are individuals, groups, or external events which can impact assets. Threats can take many forms, including people (such as insiders or Internet users), technology (such as worms or Trojans), and events (such as flood or fire). The project team works with the enterprise to identify the threats that may impact identified assets. To ensure that all credible threats are considered maintain a list of various threat types.

Our approach to threat identification is based on threat modeling – building scenarios that reflect possible events. Each asset is analyzed from the perspective of the impact (liability) of various threats scenarios. Examples of impact produced by threats include:

• Direct costs from physical destruction / loss
• Direct costs from theft / extortion
• Costs to resolve incidents (internal productivity loss, outside resources)
• Loss of consumer confidence
• Failure to meet regulatory requirements
• Failure to meet contractual agreements
• Worst case scenarios (catastrophic failures of information systems that result in physical destruction, death, injury, or an inability to continue operations)

The scenarios listed above can only happen if a threat impacts an asset that has a vulnerability. However, understanding how the threats might impact an enterprise’s business is an important step in the process. The output of this stage is a ranking of threats based on their prevalence. Prevalence is a measure used to indicate if a particular threat has the capability and motivation to impact each asset.

Rank threats on the following scale:

• High – threat has capability and motivation to destroy / compromise asset function
• Medium – threat has capability and motivation to degrade asset function
• Low – threat has minimal capability and motivation to affect asset

Capability and motivation are important attributes of threat. Threats need both attributes to be credible. For example, consider the scenario when the threat is an Internet attacker and the asset is an e-commerce server connected to the Internet. The attacker has motivation in the form of monetary gain and capability via hacking skills. Each identified asset is analyzed based on the threats that have the ability to affect them, and each threat is ranked based on prevalence.

The results of threat modeling are recorded. The asset and threat information collected thus far provides possible impacts to the business. However, the likelihood of these impacts cannot be determined without the final component of the risk assessment, which is the vulnerability assessment.

Analysis

The results of the information gathering phase is a collection of data which represents the assets critical to business operations, the threats that may impact those assets, and the vulnerabilities resident on those assets. Risk is present when critical assets, credible threats, and existing vulnerabilities are present.

As the goal of the risk assessment is to identify and prioritize risk to guide the formulation of security strategies, focus on a qualitative risk assessment rather than attempting to assign monetary values to potential losses. It is more practical to use this approach because of the limited data available on likelihood and costs and the difficulty in accounting for liability such as the loss of consumer confidence.

Through a strategic approach to Risk Assessment, this process enables organizations to optimize their security investments and proactively protect their most important information assets from potential threats. When you protect the right assets from the right threats with the right measures, you maximize your security ROI.

Chart your Course with a Security Roadmap

With initial coordinates established develop your security roadmap. After ascertaining risk within the environment, the next step is to develop strategies to manage that risk. Risk exists due to the convergence of assets, threats, and vulnerabilities, and accordingly mitigating controls which reduce one or all of these factors will reduce the overall risk to the organization. Focus on strategies that maximize return on security investment (ROSI) – strategies that result in the maximum reduction in risk for the minimum security investment.

The security roadmap clearly represents the risks faced by the organization, and risk management strategies that can be employed to reduce those risks. Risk management strategies fall into four categories:

• Risk Mitigation – Today’s security risk management is primarily mitigation – reducing exposure through security countermeasures (People, Process, and Technology)
• Risk Transfer – Risk is transferred (contractually) to a 3rd party, e.g., outsourced or an insurance provider
• Risk Avoidance – Risk is avoided (i.e., such as eliminating an existing online or network capability)
• Risk Acceptance – Risk is accepted. Certain risk is cheaper to accept than fix. There is a point of diminishing returns with security spending versus return.

Risk mitigation remains the most common security Risk Management strategy because much of the risk associated with security cannot be transferred or avoided – it must be reduced. Strategies are prioritized based on the amount of risk reduction they produce, and the relative cost. The results are documented in the security roadmap action plan.

In a future blog we will discuss more about developing a Reference Design Architecture that aligns with improving Security Capability Maturity and evolves as part of the Adaptive Security Architecture Lifecycle.

Thanks for your interest!

Nige the Security Guy.

Security Health Check

Security Health Check

Many companies have the notion that “once secure, always secure.” But this head-in-the-sand attitude could be detrimental to the health and security of your business. The reality is that security incidents are on the rise, and attackers are more sophisticated and better financed than ever before. Your company might already be a victim, and you don’t even know it.

How can you protect your information?

Security Assessment Baseline

Organizations should seek 3rd party independent and objective validation via regular security assessments, such as a Security Health Check. The main goal of a Security Health Check is to help avoid security compromises on hosts and network environments.  It is an assessment-only project which provides recommendations, no changes in the environment are ever made.

A Security Health Check enables organizations to obtain an accurate representation of the security posture and develop a customized security baseline. The baseline should be used in a cyclic and iterative process to evolve towards becoming more secure and thus compliance with associated policy and regulatory requirements. Security is a process not a destination.

A Security Health Check should cover these fundamental process steps:

• Baseline>Refresh – Identify/refresh objectives based on industry, policy, regulations, risk tolerance, and so on
• Snapshot – Security Program Assessment, Technical Security Assessment, Penetration Testing
• Scorecard – Standards or Compliance-based Security Report and Executive Presentation
• Workshop – Validate Findings and develop Prioritized Remediation Action Plan based on Risk/Threat
• Roadmap – Annual Plan of Next Steps based on Budget and Resources

There are two key yet highly complementary approaches to network security testing: the “black-box” zero-knowledge  external penetration study and the “white-box” onsite security vulnerability assessment.

White-Box Testing

In the “white-box” approach, 3rd party consultants validate your company’s security policy, review the design and implementation of  internal security controls, network security perimeter, defense-in-depth strategy, and determine common vulnerabilities and exposures  from an internal perspective. The consultants determine possible attacks against your environment and identify security problems and  process maturity.

Black-Box Testing

In the complementary “black-box” approach, the consultant operates knowing only the name and address of your company. The team will identify, scan, and probe your network security perimeter for common vulnerabilities and exposures, much as a hacker would. The external penetration study provides real-world attack experience utilizing commonly used hacker scanning, manual techniques and attack tools to determine security exposures and vulnerabilities.

The testing is conducted in parallel with the onsite security assessment team and is coordinated closely with the project manager. The penetration study methodology is typically based upon and uses subsets of, as follows:

• Penetration Testing Execution Standard (PTES)
• Open-Source Security Testing Methodology Manual (OSSTM)
• INFOSEC Assessment Capability Maturity Model (IA-CMM)

Security Scorecard

A Security Scorecard should consist of detailed penetration study and security assessment reports together with executive summary slides. This package presents the findings and recommendations on identified Common Vulnerabilities and Exposures (CVE), regulatory and standards compliance gap matrices, and provides custom best-practices-based security strategy and summary scorecards.

Remediation Workshop

The collaborative workshop provides the opportunity onsite to review, validate, and prioritize the findings, and discuss methodology, best practices, and strategy recommendations to create an action plan. These results facilitate development of a comprehensive yet improving security program and annual lifecycle process. The workshop can often include security training on the techniques used by attackers to map, probe, and scan computers from the Internet or to increase user awareness and education.

Thanks for your interest!

Nige the Security Guy.

Develop Security Architecture

Develop Security Architecture

The next step is to build the security architecture and migration strategy. This strategy lays the foundation for a successful deployment and the ongoing integration of additional applications and services. We cannot emphasize enough that the quality of up-front planning is one of the biggest factors determining the success and degree of payoff from a security project.

This section enables organizations to assemble and align the pieces necessary to develop, update, or validate a modular and flexible security architecture. The goals are as follows:

• Identify and review business objectives
• Identify and review current architecture, its implementation, and strategy
• Identify and review security policy, privacy issues, risks, and associated liability
• Align the security architecture with the business plan
• Validate the architecture against requirements
• Document the security architecture and gain consensus and buy-in
• Develop and guide a two to three-year adaptive migration strategy
• Spawn projects to realize budgeted and prioritized subcomponents

Developing a security architecture and migration strategy should be accomplished in four phases. The first two phases involve doing your homework: identifying the business drivers, defining and collecting requirements, and assessing the current infrastructure environment. With a solid base of requirements, you can proceed to develop the security architecture and migration plan.

Identify IT Principles, Business Drivers and Requirements

To inventory your current business drivers and requirements, you must identify and interview the business units, asset, and application owners. To do this you need to use effective survey instruments and summarize the resulting interview notes in a clear (sometimes even tabular) form. It’s important not to start with a blank slate. Instead, begin with good interviewing instruments such as survey questionnaire templates.

You should also learn about the corporate culture and the enterprise IT Architecture Principles. Determine the opinions of IT executives and your sponsor about issues such as single-vendor versus best-of-breed environments, insourcing versus outsourcing, technology risk taking versus technology conservatism. You will want to know whether managers take strong positions or keep to the middle of the road and to align yourself with those positions when appropriate.

Your general-purpose security infrastructure needs to meet a number of functional, performance, cost, and process requirements across an evolving extended enterprise. Thus, a prioritized business requirements analysis summary is the output from the business driver identification and requirements process. This requirements list is the foundation for your architecture and migration strategy.

Once you have a detailed requirements list that combines generic requirements with those gathered from the interviews, you should prioritize and categorize the requirements. This process should involve the extended project team to maximize buy-in and ensure that the requirements have legitimacy.

Assess the Current Infrastructure Environment [Current State]

Today’s enterprise network tends to be very fragmented and quite complex— hindering even the best efforts to secure systems. The disparate nature of your network creates inherent weaknesses in your organization and in your ability to control information privacy, access, and movement. The issue is exacerbated by the rapid pace of migration to diverse modes of processing, which is driven by user demands, technological evolution, off-the-shelf applications, and their inability to integrate.

Performing an assessment assists you in understanding the issues, shortfalls, and what risks your organization is exposing its infrastructure to. If you are a publicly held company, or are planning to go public, the Securities and Exchange Commission (SEC) requires that you understand all your corporate risks, and convey this information to your potential investors in your prospectus. Having an assessment done by an independent external authority demonstrates that your organization has observed due diligence and objectivity in working toward a secure infrastructure.

An assessment demonstrates management’s due diligence to ensure site availability, data integrity, and information protection for your organization, partners, and customers. It does not guarantee that your site cannot be successfully attacked or compromised. The report does, however, give you a profile of your security posture at a given snapshot in time. This profile can be used as a guide (the current state) that can be contrasted against the security architecture (goal state) and a gap analysis conducted to develop your migration strategy. See Adaptive Security Architecture Lifecycle blog.

The security-focused infrastructure assessment also benefits you by facilitating improvements as follows:

• Service customer expectations and build customer loyalty
• Reduce site outages and performance problems
• Create secure and seamless information access
• Take precautions during acquisitions or mergers
• Meet contractual obligations
• Gain competitive advantage
• Enable corrective action
• Qualify for information protection insurance

Penetration Testing

Penetration testing can use many methods to attempt a system break-in. In addition to using active automated tools as described above, penetration testing can be performed “manually.” For many systems, default configurations, lax patch procedures or a lack of internal controls on applications are common vulnerabilities that penetration testing can target. Penetration testing is a very powerful technique; preferably, it should be conducted with the knowledge and consent of management. A large organization may do well to begin by taking stock of how many vulnerable systems are present in their organization, thereby measuring trends in their network security maturity and compliance to configuration standards.

While penetration studies provide necessary and valuable data on vulnerabilities and exposures, they are symptomatic of a major problem that really needs to be addressed in multiple areas. These include the source, in vital processes that wrap around the architecture, such as configuration management, and the integration and automation of security management (Network Behavior Anomaly Detection, or NBAD).

Develop Security Architecture [Goal State]

The security architecture serves as an evolving technical blueprint for the next two to three years of your infrastructure. It may be a vendor-neutral framework or it may specify vendors. This depends on whether you want to cut to the chase and deploy right from the architecture or whether you plan to use the architecture as an intermediate step moving toward product selection and procurement processes. A vendor-neutral framework should be provided in either case, if only as a yardstick for evaluating solutions.

The architecture should be based on product capabilities that are here today, but it should also anticipate and adapt to emerging trends that will become important in the next two to three years. The architecture should be based on your organization’’s IT Architecture Principles, and it should recommend high-level transition or migration strategies for product selection, implementation, and deployment. In addition, it should provide a high-level risk analysis and risk mitigation strategy.

It should also define your organizational framework for managing security services, examples such as:

Develop Migration Strategy and Plan

As we’’ve said, the architecture should be accompanied by a migration strategy with recommendations for product selection, implementation, and deployment. The migration strategy should provide customers with a transition plan, high-level risk analysis, and risk-mitigation strategy. It should define an organizational framework for managing security services. It may also include cost estimates and other data requested by management.

Conducting a migration strategy planning workshop is an excellent vehicle to bring all of the stakeholders to a common, shared level of understanding. It is an opportunity to sell the security architecture and reach consensus, consider the various functional components that are required and, based upon need, factor in dependencies and priorities. For example, security services such as access management portals require a trusted time service as well as general-purpose directory service. Therefore, the real supporting infrastructure need is identified with everyone present, and funding is justified and committed.

The transition plan is especially important. Security architecture projects are large and multi-faceted, typically requiring months or years of ongoing effort. It is possible to get bogged down in analysis paralysis and emerge from months of planning with no tangible accomplishments to show for the effort. Therefore, architecture and migration planning efforts should proceed as time boxed activities, each lasting a few weeks or months and culminating in functional consensus and iterative improvement.

The first major milestone in your transition plan is completing the baseline security architecture and migration strategy. A second could be completing product or solutions procurement. The third milestone lies in achieving a production security infrastructure deployment. Achieving this milestone should take several months, provided you have the resources for detailed design, implementation planning, and solutions development.

Once in production, you’’ll have a working model that demonstrates some of the benefits of a general-purpose security infrastructure and provides a solid foundation for ongoing security integration and consolidation. To complete an initial production solution in a reasonable period, however, you must not only have resources, but you must also limit the scope of the undertaking. The best plan is to pick low-hanging fruit by integrating a few applications or services at a time.

The next blogs in the series will offer advice on, as follows:

• Product and Solution Selection
• Implementation Planning
• Operations Cutover
• The Adaptive Security Lifecycle

Thanks for your interest!

Nige the Security Guy.