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 Management

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.

Closed Loop Policy

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.

Asset Discovery and Catalog

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).

Infrastructure Integrity

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

Risk Analysis

“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.

RAP

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:

Vulnerability Lifecycle

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.

Root Cause Analysis

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.

Advertisements

ISO 27002 Security Benchmark

ISO 27002 Security Benchmark

Information security plays an increasingly crucial role in protecting the assets of an organization. As no single formula can ever guarantee 100% security, there is a need for a set of benchmarks or standards to help ensure an adequate level of security is attained, resources are used efficiently, and the best security practices are adopted. This blog illustrates a basic methodology to perform an ISO 27002 Security Benchmark and how to evolve towards compliance and become increasingly secure = integration with a Capability Maturity Model (CMM).

Maze

What are the Benefits?

ISO 27002 provides organizations with the assurance of knowing that they are protecting their information assets using criteria in harmonization with an internationally recognized standard. Benefits are applicable to organizations of all sizes and all security maturity levels, not only large enterprises.

Organizations with superior IT governance have more than 25% higher profits than those with poor governance
given the same strategic objectives. These top performers have custom-designed IT governance for their strategies.

ISO 27002 compliance can provide many benefits:

  • Provides a framework for resolving security issues
  • Provides policies & procedures in accordance with internationally recognized criteria, structure and methodology
  • Enhances client confidence & perception of your organization
  • Enhances business partners’ confidence & perception of your organization
  • Provides confidence that you have minimized risk in your own security program
  • Can be a deciding differentiator in contract negotiations
  • Enhances security awareness within an organization
  • Assists in the development of best practice
  • A defined process for implementation, management, maintenance and ISMS evaluation
  • Evaluations conducted by impartial independent and objective assessors using a proven methodology
  • A performance yardstick to harmonized criteria resulting in mutual recognition
  • Optimized security delivers lower costs: fraud, inefficiency and errors should be reduced
  • May reduce insurance premiums
  • Compliance advantages for participation in Global business opportunities

Leveraging internationally renowned security standards not only allows organizations to seek a reasonable goal of due-diligence but also enables them to articulate security posture to external partners and customers.

ISO 27000 Standards Family

ISO/IEC 27001, part of the growing ISO/IEC 27000 family of standards, is an Information Security Management System (ISMS) standard published in October 2005 by the International Organization for Standardization (ISO) and the International Electro-technical Commission (IEC). An Information Security Management System is a systematic approach to managing sensitive company information so that it remains secure. It encompasses people, processes and IT systems.

ISO/IEC 27002 is a Code of Practice for Information Security Management standard. It provides best practice recommendations on information security management for use by those responsible for initiating, implementing or maintaining information security management systems (ISMS). The Code of Practice establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.

ISO 27002 Scope

Within the Code of Practice there are a set of security domains, as follows:

  • Risk assessment – see blog Risk Assessment and Roadmap
  • Security policy – management direction
  • Organization of information security – governance of information security
  • Asset management – inventory and classification of information assets
  • Human resources security – security aspects for employees joining, moving and leaving an organization
  • Physical and environmental security – protection of the computer facilities
  • Communications and operations management – management of technical security controls in systems and networks
  • Access control – restriction of access rights to networks, systems, applications, functions and data
  • Information systems acquisition, development and maintenance – building security into applications
  • Information security incident management – anticipating and responding appropriately to information security breaches
  • Business continuity management – protecting, maintaining and recovering business-critical processes and systems
  • Compliance – ensuring conformance with information security policies, standards, laws and regulations

These security domains contain control objectives with hundreds of best-practice information security control measures recommended for organizations to satisfy the control objectives and protect information assets against threats to confidentiality, integrity and availability.

Capability Maturity Model (CMM)

A Capability Maturity Model (CMM) is a model for judging the maturity of the processes of an organization and for identifying the key practices that are required to increase the maturity of these processes. The idea behind a Security CMM is to define areas of a security program that should have policy. procedures, processes and controls associated with them and then to measure the application and effectiveness of the policy. procedures, processes and controls (capability level) in an organization. A more mature organization is defined as one whose processes are better defined, integrated and managed. Such an organization is said to have a higher capability level than a less mature organization.

The Security CMM defines five capability levels:

Security CMM

ISO 27002 Benchmark

There are many tools and templates available that can help an organization to benchmark their current state towards ISO 27002 compliance. In our case we developed an Excel macro-based tool that factors both ISO 27002 controls as well as maps them to CMM. The user simply makes selections based upon drop-down boxes and adds comments on any observations. See the ISO 27002 Benchmark Visualization Tool sample below:

ISO 27002 Tool

The tool is used in interactive sessions with IT to discuss the various domains and controls of ISO 27002 and their current state in terms of development, implementation, integration and, maturity. The results are summarized in the checklist as well as the controls are validated to ensure accuracy. Once the exercise has been completed for all sections within ISO 27002 then the macros can be executed. They operate against a default template report in our case to auto-generate the report and enable an efficient and rapid benchmark. The deliverable report is then further developed with placeholder sections to customize and add expertise, industry trends and best-practices to management. An extract of the raw report is shown below.

ISO 27002 Report

The tool additionally auto-generates ISO 27002 Security Benchmark Executive Summary slides that further enable presentation and visualization to executive management on current state as well as the organization’s objectives, enabling ongoing justification and support for the cost and resources needed for the security management and improvement program. The following is a sample of a high-level graph that maps compliance to organizational objectives and CMM.

ISO 27002 Visualization

“Security is not a product, it is the ever evolving integration of solutions and process based upon
industry standards, proven methodology and, best practices.” Nigel Willson

ISO Scorecard 2

ISO 27002 Compliance Lifecycle

Once the organization has performed an initial Baseline Benchmark then the results can be evolved into an on-going lifecycle benchmark process and ISO 27002 compliance measurement program. Performing benchmarks quickly and efficiently reduces the burden and enables timely reporting on progress, depending upon organization’s size that is quarterly, bi-annually or, annually. It can be used to demonstrate progress and trends in what has been achieved and what is left to do. The following is a high-level example ISO 27002 Compliance Lifecycle.

  • Baseline Benchmark – Assess the status of security management processes and controls
  • Regular Checkpoints – Perform periodic health checks to compare and contrast improvement and compliance progress
  • Identify Gap – Use gap analysis to identify the divergence of current state security against the standard goal
  • Statement of Applicability (SOA) – Describe the relevance of the standard’s controls to your organization
  • Security Improvement Program (SIP) – Develop cyclic process to recommend the measures required to overcome the divergence identified in the gap analysis

Critical Success Factors

Experience has shown that the following factors are often critical to the successful implementation of information security within an organization:

  • Information security policy, objectives, and activities that reflect business objectives
  • An approach and framework to implementing, maintaining, monitoring, and improving information security that is consistent with the organizational culture
  • Visible support and commitment from all levels of management
  • A good understanding of information security requirements, through the use of risk assessments, and risk management
  • Effective marketing of information security to all managers, employees, and other parties to achieve awareness and ultimately compliance
  • Distribution of guidance on information security policy and standards to all managers, employees and other parties
  • Provision to fund information security management activities
  • Providing appropriate awareness, training, and education
  • Establishing an effective information security incident management process
  • Implementation of a measurement system used to evaluate performance in information security management and feed back data for improvement.

Scorecard

Conclusion

Management support is necessary at all levels. User awareness programs should also be conducted to ensure that all employees understand the benefits and impacts before the deployment of new security policies and guidelines.

A common problem that crops up after implementation of a standards alignment exercise is an increase in the number of complaints received from users of IT services due to the restrictions imposed by new security controls. The successful implementation of any information security standards or controls must be a balance of security requirements, functional requirements and user requirements.

Stop Think

Although there are a number of information security standards available, an organization can only benefit if those standards are implemented properly. Security is something that all parties should be involved in. Senior management, information security practitioners, IT professionals and users all have a role to play in securing the assets of an organization. The success of information security can only be achieved by full cooperation at all levels of an organization, both inside and outside.

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

Chart Course

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

Assets Risks Threats

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.

Risk Framework

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.

Security RDA Evolution

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.

Security HealthHow 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.

Health Check

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.

White Box

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.

Black Box

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.

Scorecard

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.

Architecture 2

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.

Extended Enterprise

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:

Example Security Services

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.

Security Architecture Dependency

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.

Risk-Aware Security Architecture

Risk-Aware Security Architecture

We continue the series to develop an on-going threat analysis and risk management process – as key requirements to guide architectural direction and also design/implementation to support mitigation of risks/threats via compensating controls and/or countermeasures or, enable the transfer of risk to other parties, acceptance as a business risk (exception process) or, seek avoidance.

Back to Security Basics

As a sidebar – the theme of the Adaptive Security Architecture Series blog is “Back to Basics“. We live in a world of rapid deployment but over time it results in a complex and fragmented infrastructure that increases the cost of operations, to manage and keep secure. The same way it is good to tidy your room and get organized, there is a continuous cycle of tidying infra and getting it organized and back in line.

Threat Level

Risk and Threat Analysis

Performing a comprehensive risk analysis with technically qualified independent and objective security consultants is the most important security activity. The risk-analysis process can logically be divided into three main activities, each providing additional insight into the security needs of the overall IT environment.

  • Sensitivity Assessment
  • Risk Assessment
  • Economic Assessment

Sensitivity Assessment is used to determine the actual value of the data and the criticality of the mission that is supported by IT resources.

Risk Assessment is the most significant activity of the overall risk analysis. It is used to define threats against the IT environment, vulnerabilities, and the risks that result from the exploitation of known vulnerabilities by the defined threats.

Economic Assessment is used to examine the potential loss expectancy given various threat execution scenarios. The Economic Assessment attempts to quantify, to the greatest extent possible, loss expectancy in terms of real dollars.

A risk analysis is based on the premise that it is not possible to have a risk-free environment. Risks, therefore, must be managed based on an organization’s tolerance. Any risk can be defined as the resultant value derived from the mapping of a potential threat against known vulnerabilities and/or weaknesses.

The qualification of risks is one of the necessary activities in determining which threats should be controlled and managed. Therefore, a risk analysis is used primarily to identify those risks that could potentially impact the secrecy, integrity, and/or operational continuity of the environment being evaluated. Insights gained from the risk-analysis process can then support risk management and the cost-effective application of security countermeasures.

Security Perimeter

Security architects should define and document the security perimeter. Defining the security perimeter bounds the problem and allows the risk analysis effort to be focused and structured. In today’s network economy, perimeter definition is somewhat complicated due to convergence of networks and the softening of perimeters into multiple layers and trust zones.

In many cases, organizations must simultaneously inter-work with mobile/remote workers; offsite contractors; partner companies with many point-to-point relationships; partly-owned subsidiaries; recent, undigested acquisitions; services outsourced to application service providers (Cloud, ASPs); e-business affiliate sites – or all of the above.

Risk ManagementProcess

Understand the Environment

The risk analysis team must spend the time necessary to understand the components and technical interactions that occur in the IT environment. The team must also understand the mission that the systems, networks, and applications support and how business requirements are satisfied through IT resources. Finally, the team must work to understand the organizations that utilize IT resources, how they interact, and any unique requirements or needs they may have.

Application Role and Relationships

System decomposition involves the logical separation of the IT environment into elements. The list includes systems, networks and applications. The resulting document must list these singly and graphically identify their inter-relationships from a dependency perspective. This is covered in more detail in a separate blog on Application Architecture Taxonomy and Application Connectivity Management and an information-centric approach to security and controls. It builds upon the asset, application and information discovery in the Security Architecture Baseline post.

Identification of Threats

Potential threats are defined for each IT element. The threat-definition process should be focused on those IT information elements more mission critical or important to operational posture or information confidentiality.

Many potential threats exist; however, the likelihood of their occurring may be negligible. Threat Rejection Logic is an important aspect of the risk-analysis process. For the purpose of performing trade-off analyses, the number of initial threat models can be large, though many are subsequently discarded as irrelevant to a particular environment. Only those threats determined to be relevant to your organization should be investigated further. Once threats are identified, analyze how those threats, through a logical threat-manifestation process, could cause one of the following events to occur:

  • Unauthorized disclosure of sensitive information
  • Unauthorized modification of sensitive information
  • Denial of service

Threats should be illustrated in threat logic tree format. A logic tree enables a specific threat to be traced from a general description (e.g., denial of service) to finer granularity (e.g., resource exhaustion). Each threat is explained in detail. For example, what does SQL injection mean and why is it a relevant threat to the network?

Vulnerability to Threats

An element’s vulnerability to a specific threat must be roughly calculated in the context of that threat’s probability of occurrence. The selection of the appropriate category or level (e.g., 3-High, 2-Moderate, and 1-Low) is a function of historical data, existing documents, practical experience, and a comprehensive analysis.

Degree of Risk

To determine any given risk level, combine and analyze the severity of the threat and the element’s level of vulnerability.

Risk Matrix

Countermeasures

Countermeasure and/or compensating control application is used to reduce risk. The value of applying a countermeasure must be quantified. In some situations, a single countermeasure can reduce or eliminate risks in several areas. For example, encrypting certain data communications reduces the risks of information compromise and information modification.

Residual Risk

Residual Risk is defined as the remaining risk value after a countermeasure(s) has been applied. Residual risk is determined by comparing the initial risk level against the utility of the selected countermeasure.

Process Iteration

It may be necessary to iterate the two previous steps until residual risk is considered acceptable. The law of diminishing returns is applicable in the application of security countermeasures. At any given time, the utility of an additional countermeasure may not increase security but may be detrimental, affecting performance and increased system maintenance costs. Risk reduction must strike a balance between the level of protection and the performance and cost of managing the security of the environment.

Benefits

In summary, several benefits are realized from conducting an on-going risk analysis and management. A risk analysis defines the system(s) being evaluated and sets the tone and direction for future security engineering activities. A risk analysis provides the ability to identify problems early in any information system program and supports expeditious problem resolution, programmatic visibility, and technical cognizance. A risk analysis provides justification for the acquisition and use of security countermeasures.

Risk Process Lifecycle

Blind application of security countermeasures, without first understanding the inherent risks of the environment, is likely to be unproductive, unjustified, and costly. A future blog in this series will cover practical Information and Data Classification.

Thanks for your interest!

Nige the Security Guy.

Think You’re Secure? Think Again.

Think You’re Secure? Think Again.

We’ve all heard the endless stories of unscrupulous individuals hacking their way into computer networks and Web sites to steal personal information and credit card numbers, or simply wreak havoc on a company. The first quarter of 2013 saw an unprecedented number of data breaches reported in both the public and private sectors of the US economy. Additionally the cost of remediation per breached record has substantially increased.

thinker

Organizations are increasingly concerned that historical industry best practices are being stressed by the acceleration of new malware and Advanced Persistent Threats (APT). The insider threat has primarily morphed into phishing attacks and APT’s which leverage multiple internal security flaws and vulnerabilities to inject an attack and use that as an exploit to ex-filtrate data and/or intellectual property un-detected.

But you made sure that a state-of-the-art security “system” was in place for your company – a cyber attack or security breach could never happen to your business. Right?

Think again. The security of your IT assets and infrastructure is vital, and ensuring that you have an up-to-date and robust system is the key to that success.

The Security Process

Today, with the advent of APTs attackers are laser-focused on multi-pronged exploits that steal data or wreak havoc.  Security is horizontal … it covers all IT infrastructure. The result is that security infrastructure becomes much more complex and fragmented. Attackers don’t discriminate and will take advantage of any gap in protection to reach their end goal. The bad guys continually evolve and innovate. All potential threat vectors need to be examined and addressed.

Chances are that when the IT infrastructure was originally deployed it was secure, clean and, organized. But as weeks, months, and even years pass, tactical changes in technology and the IT environment have probably occurred, weakening the security posture and opening it up to attack. Without a proactive but practical security strategy and processes in place that routinely deploy within a security model,  identify controls, mitigate new technologies, and upgrades … the system will inevitably become vulnerable and fail.

There aren’t enough hours in the day, IT security teams have too many other responsibilities to be able to address today’s barrage of attacks with manual approaches. The ability to reduce labor intensive tasks and streamline processes with automation is essential. Holistic consolidation, integration, organization and … automation leveraging refresh and upgrades to evolve iteratively towards a cohesive Secure Immune Security System is a must in order to cope.

bacteria-generic-110121-02

Secure Immune Security System

How do organizations cut through the hype, filter the noise … of fear, uncertainty and, doubt (FUD) and deal with real and present threats? How do organizations develop an affordable Secure Immune Security System that supports the business based on resource profile and — enables it to grow competitively while managing risk and protecting critical assets? How do organizations develop a continuous cycle to consolidate, integrate and organize mission critical infrastructure into a sustainable core while still enabling some healthy chaos and innovation on the edge?

This series of articles will seek to help organizations, big or small have the practical process, technology and strategy needed to ensure Proactive Defensible Security Posture. A defensible security posture leveraging a Secure Immune Security system together with strong Security Infrastructure Operations Management and refreshed by an Adaptive Security Architecture Lifecycle provides the confidence that your systems are safe or — if a breach does occur to effectively: Protect, Detect, Contain, Eradicate, Recover.

During an attack, the ability to continuously detect threats and block them is critical. After an attack, marginalizing the impact becomes the priority. To do this defenders need to take a proactive stance with retrospective security, the ability to identify the root cause, understand the scope of the damage, contain the event, eliminate the risk of re-infection, remediate it and bring operations back to normal.

pc_vs_network_vs_mobile

Simplicity the Path to Better Security

The secret to success in security is typically simplicity, to have a well designed and organized infrastructure that provides the appropriate layer of controls while enabling users a consistent ‘policy managed’ experience regardless of location, transport or device. The challenge is in achieving that goal. Stay tuned for more information on lessons learned and experience from the field, success stories and, practical case studies. Coming soon the Security Architecture, Strategy and, Roadmap series.

Thank you for your interest.

Nige the Security Guy.