Security Series Master Index

Security Series Master Index

This blog will be maintained to provide a Security Series Master Index summary of all of the blogs to assist in site exploration and navigation – as well as preview upcoming blogs.

The currently planned series are, as follows:

• Security Architecture Series
• APT Strategy Series
• Security Governance Series
• Risk Management Series
• Security Assessment Series
• Miscellaneous Topics

Security Architecture Series

The Security Architecture Series build upon each other and contains:

• Think You’re Secure? Think Again.
• Security Architecture Primer
• Security Architecture Baseline
• Risk-Aware Security Architecture
• Develop Security Architecture
• Product and Solution Selection
• Security Architecture Implementation
• Adaptive Security Lifecycle
• Architecture Case Study – Part 1
• Architecture Case Study – Part 2

APT Defense Strategy Series

The APT Strategy Series contains, as follows:

• APT Strategy Series
  • An introduction to the APT Strategy Series together with the rationale behind the need for a well-designed Secure Architecture and Design foundation
• Defensible Security Posture
  • The basic idea of a Defensible Security Posture is that you aren’t striving for an absolute, but rather for a position (or posture) that is able to be defended even when it’s infiltrated
• Defensible Security Posture – Part 2
  • How can you leverage the Defensible Actions Matrix? A defensible actions matrix defines processes and procedures that can impact an attacker’s capability at various stages of the cyber kill chain.
• Advanced Threat Defense – Part 1
  • Focuses on top-down Architecture & Strategy to address Advanced Threats with ability and visibility to Detect and Contain
• APT Defense Puzzle
  • Focuses on bottom-up Actionable Security Posture Improvements: Checks, Practices, Controls, Indicators
• APT Detection Framework
  • In order to begin to understand and to be able to defend against targeted attacks a detection matrix is needed for visibility, analysis and, to ensure that all threat scenarios are considered with no gaps in defense
• APT Detection Framework – Part 2
  • There is a trend underway in the information security field to shift from a prevention mentality — in which organizations try to make the perimeter impenetrable and avoid breaches — to a focus on rapid detection, where they can quickly identify, contain and mitigate threats.
• APT Detection Indicators – Part 1
  • In a world where organizations need to be watching or monitoring their networks continuously knowing what to look out for is critical
• APT Detection Indicators – Part 2
  • Advanced Persistent Threats (APT) typically exhibit recognizable attributes and patterns that can be monitored by readily available, open source tools
• Adaptive Zone Defense – Part 1
  • Limiting and intelligently managing communications between services and systems on an organizations network helps contain an infection or compromise to keep malware or a persistent threat from running rampant
• Adaptive Zone Defense – Part 2
  • In Adaptive Zone Defense – Part 2 we develop another key foundation, known as Application Architecture Taxonomy that talks to application and system placement, organization and, management within the proposed zones.
• APT Red Teams – Part 1
  • How do you prevent an APT? Red Teams enable continuous improvement and optimization from counter-intuitive sources to help mitigate advanced threats
• APT Red Teams – Part 2
  • Addressing security more aggressively and working to identify areas of weakness is a more sensible, and ultimately, more effective approach than working to build a “bigger wall” that you hope attackers can’t get through
• APT Response Strategy – Part 1
  • How do you implement a Plan C? Organizations are starting to recognize the ever increasing importance of rapid and well orchestrated incident response capabilities as a key component in their defense-in-depth strategy.
• APT Response Strategy – Part 2
  • [Coming Soon]
• APT Threat Analytics – Part 1
  • How can you predict emerging threats? Threat intelligence and analytics continues to dominate the headlines and attention of organizations seeking viable options in their escalating battle against advanced threat actors.
• APT Threat Analytics – Part 2
  • With the increase in advanced, multidimensional threats, more and more organizations are considering development of an in-house threat intelligence program
• APT Operational Maturity – Part 1 [Coming Soon]
  • How can you evolve towards effective Visible Security Operations? An update to my 90’s Security Maturity Model based on recent sophisticated threats and determined attackers.
• APT Intelligent Operations – Part 1 [Coming Soon]
  • How can you build an Intelligence-Driven Security Operations platform using commercial and/or open-source tools.

Security Governance Series

The Security Governance Series contains, as follows:

• Security Program Best-Practices – Part 1
• Security Program Best-Practices – Part 2
• Security Program Best-Practices – Part 3
• Security Program Best-Practices – Part 4
• Security Program Best-Practices – Part 5
• Risk Management Strategy [Coming Soon]
• Data & System Classification [Coming Soon]
• Identity Management & Role-Based Access [Coming Soon]
• Next-Generation Intrusion Prevention (IDPS) Strategy [Coming Soon]
• More to follow

Security Assessment Series

The Security Assessment Series contains:

• Common Compliance Framework [Coming Soon]
• Vulnerability Assessment Remediation
• Threat and Vulnerability Management
• APT Threat Assessment
• Penetration Testing and Security Validation [Coming Soon]
• Risk Assessment and Roadmap
• ISO 27002 Security Benchmark
• Security Health Check

Thanks for your interest!

Nige the Security Guy.

Adaptive Security Lifecycle

Security as a Business Enabler

Infrastructure and the environments in which they operate are dynamic and continually evolving over time, especially in our rapid deployment world. Many fast-tracked organizations start out with a well-designed, orchestrated and secure architecture but organically, like Firewall rules it devolves and diverges into increasing levels of complexity and fragmentation.

Applications and systems grow exponentially creating increasingly complex connectivity and relationships that result in a spiders web of interfaces across domains. Complexity leads to insecurity, increased risk of human error and, a substantial increase in the cost of operations and maintenance. The result dramatically impacts the organizations ability to deploy rapidly and efficiently and move forward with agility.

“Security done right is a business enabler that dramatically reduces total cost of ownership (TCO)
providing a tangible Return on Security Investment (ROSI).

IT complexity and fragmentation replaced by an adaptive modular and flexible architecture enables agility and
improves your competitive edge — so the business can refocus quickly as new opportunities emerge.

Security is a process, not just a product or technology issue.”

Adaptive Security Lifecycle Process

System technology and users, data and information in the systems, risks associated with the system, business drivers, and security requirements are ever-changing. Many types of changes affect security: technological developments (whether adopted by the system owner or available for use by others); connection to external networks; a change in the value or use of information; or the emergence of a new threat.

Creating an adaptive modular architecture leads to agility and flexibility as the organization grows. Like  keeping your room tidy there needs to be a healthy amount of chaos and innovation on the edge with a continual process of consolidation, integration, organization, and so on into the core. Organizations across various regulatory requirements have fallen into the trap of only seeking compliance – which can be far from being secure. Security is part diplomat, part salesman, part an art.

In addition, security is never perfect when a system is implemented. System users and operators discover new ways to intentionally or unintentionally bypass or subvert security. Changes in the system or the environment can create new vulnerabilities. Strict adherence to procedures is rare, and procedures become outdated over time. These issues make it necessary to periodically reassess security architecture.

An adaptive security lifecycle process develops an architecture that is refreshed on an annual basis. The first step in the process is to develop the current state (see below). The results of the security baseline that were formed in a previous blogs, together with the assessment conducted (current infrastructure environment), are analyzed. Factors such as the perimeter, hybrid cloud(s), data center(s), DMZs, Virtual Private Networks (VPNs), virtualization, intranet, extranet, partner connections, remote access, and access to assets, are considered to develop the current state and security risk profile.

Adaptive Security Architecture Methodology

The next step is to develop the security architecture (see: Develop Security Architecture blog), which creates the goal state. This process takes the current state and security-risk profile documented previously and adds the business drivers, prioritized requirements, policy, legal constraints, and so on. From this step, a formal security architecture is developed and shared with the stakeholders to gain consensus.

The final step is to compare the current state with the goal state and to identify the projects that are required to transition the current infrastructure and realize the architecture. From the migration strategy workshop (see: Security Architecture Implementation blog), together with the business units and stakeholders, the viable projects are selected based upon their dependencies, priorities, available resources, and budgets forming the annual plan of infrastructure improvements.

During the next planning year, the process is repeated and the architecture updated with new business requirements, new technologies, new solutions, and so on. A follow-on assessment of the current infrastructure captures improvements together with any new threats, vulnerabilities, and exposures, and documents the new current state and security-risk profile. Performing a gap analysis and migration strategy planning workshop contrasting the new current state and goal state allows an updated plan to be developed for that year.

Adaptive Architecture Value Proposition

Over time, it can be seen (see: Adaptive Architecture Evolution above) that the security architecture is used as a baseline for consensus and direction but that it is active and capable of being updated. This process allows the security architecture to adapt to support the needs of the business. It evolves and sets future objectives. It enables an iterative evolution towards compliance across an applicable regulatory and standards-based Master Compliance Framework.

At the same time, the annual plan sets the stage for the projects that need to occur that year, and the improvements begin to converge towards and track with the architecture. Finally, with the proactive asset, risk, and policy management and infrastructure improvements, the security-risk profile is also managed, resulting in risk reduction. In this manner, not only does the security architecture drive the IT and network infrastructure direction, but it also enables the illustration of tangible results, winning continued support for the program.

The next blogs will cover the Application & System Zoning as well as Application Architecture Taxonomy to untangle the spiders web of complex critical applications and relationships for zone placement, policy and, controls.

Thanks for your interest!

Nige the Security Guy.

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

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:

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:

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.

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.

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

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.

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.

Security Architecture Implementation

Security Architecture Implementation

This blog continues the Security Architecture Series by building a Back to Basics foundation before developing upon that foundation with adaptive security in hyper-extended enterprises for a defensible security posture.

The security architecture defines and justifies a number of solution implementation, integration and/or improvement projects each year, based on budget, resources and, priority. As such, a master project plan should be created that takes into account identified dependencies, integration points and any parallel tasks.

To plan implementation of a security solution, you must identify where project execution resources will come from, develop an implementation plan, obtain buy-in for the implementation plan, and create a detailed design for the configuration and deployment of the security infrastructure.

Implementation planning must be viewed as a process first and documents second. In addition, you should keep the technical staff or consultants used during the architectural review on tap to provide implementation planning process oversight. In many projects we have used a Program Technical Architect as the keeper of the vision, direction and, strategy.

Identify Project Resources

First, you must understand and define the scope and resources required for the  deployment. These resources include the following:

• Security project manager
• Support functions (administration, contracts, procurement, and others)
• Security engineering development staff (own and vendor’s)
• Security integration team (including part-time contributors and other support organizations within your environment)
• Network operations staff
• Ongoing security operations and support staff

Unless you have a particularly strong and deep security development team on staff, many organizations don’t you will want to make use of vendors’ professional services. They can, or should, be able to install, configure, and do development work for your product better than anyone else.

However, you’ll also need to have a strong complement of dedicated staff involved with managing and developing the security infrastructure during its early deployment. You also need to have good relationships and well-spelled-out agreements with staff borrowed from other internal functions.

Ultimately, day-to-day operation and support of the security infrastructure will be turned over to an operations organization. However, a security project manager and a few technical support and development resources should remain in place for ongoing integration. You’ll also need staff for pre-production validation, security audit, monitoring, and incident response.

Develop Implementation Plan

The implementation plan should:

• Restate the architecture as a high-level design, plugging in the selected solution components
• Propose a security implementation team (which may be similar or overlapping with the original security architecture team)
• Define an overall project plan and detailed project schedule
• Identify required resources and other critical success factors, such as a test lab, pilot participants, firewall, or other application configuration changes that must be agreed upon far in advance
• Define project completion and acceptance test plan
• Write an execution-focused risk analysis and mitigation plan
• Develop a communications and training plan
• Compile cost estimates

The architecture, the vendor’s proposal, the high-level design, early project plans, and other working documents prepared during the project must all be consumed, synthesized, and polished to create a realistic implementation plan for going forward (see Security Plan Template). The devil is in the details and time invested upfront in planning and preparation is proven to save lots of time and enable success in implementation and cutover.

However, the high-level design and implementation plan needs to be more than just a piece of paper. Selling the security project is an on-going process.

Implementation planning may well be combined with obtaining the funding and approval to purchase off-the-shelf solution components. It should also be at this point that explicit commitments are obtained to rely on part-time, cross-functional security integration team members. Once obtained, these commitments must be continually reconfirmed; projects fail for lack of stakeholder commitments to do their part for interconnection or configuration.

Obtaining Buy-In and Support

An implementation plans success also depends on the vendor(s). Vendors will provide resources for some stages of the plan, and vendors will be dependent on some of the plans customer-provided deliverables, such as a test lab. The full plan requires a successful triumvirate of dedicated security staff, vendor staff, and the staff of the cross-functional resources that will be integrated or consolidated in this initial implementation.

Think of an implementation plan as a process as much as a document. Your security implementation and deployment will depend on the efforts of many people, and they must be engaged in and buy into both the planning process and the activities it entails. Anticipate that the vendor(s) will have to make changes to accommodate your needs. Expect some push back from vendors and cross-functional team members.

Develop Detailed Design and Test Plans

At this stage, a security project moves from architecture and high-level design to detailed design. This process must be conducted by the vendor or at least in close collaboration with the vendor. However, you will want to keep your technical staff or consultants on hand to ensure that the design stays true to the architecture.

Detailed design refines each of the security projects physical, logical, integration, access, management, and administration fine points. It identifies deployment details down to the configuration of roles, entitlements, or attribute syntax.

In parallel with developing the detailed design, an enterprise needs to create detailed test plans. Testing should not be done as an afterthought. It should be baked into the design, roll out, and acceptance process.

Operations Cutover

When a key part of the security architecture has been realized, the solutions selected, and the infrastructure implemented and tested, it is time to wrap process around that architecture and transition to the team that will operate and support it. If not, then the architecture and engineering teams will be burdened by the new infrastructure, limiting their ability to move forward strategically. The architecture and security engineering teams will shift their focus to further communicating, developing, and validating the architecture and realizing the next project phase, while at the same time providing tiered support to the operations personnel.

This section enables you to document the all-important processes and procedures for cutover, identify operations roles and responsibilities and don’t forget to —conduct user awareness and training to fully complete the deployment.

Document, Document, Document

Security support functions fill a vital role within the security of any system. Security standards, procedures, and checklists are recommended as they guide the day-to-day security activities. These processes and procedures should be developed by a knowledgeable person, and be reviewed, documented, formally published, and given to management and staff personnel. The development of procedures helps support a consistent application of the security policy.

Identify Responsibilities and Train Operations

The continuity of service and the high availability of IT services are imperative to the success of operations. Those imperatives will play an increasingly important role in the future. Once a security solution is implemented, there must be someone who is ultimately in charge and who has the responsibility to ensure implementation consistency. The most effective way of ensuring this is through management visibility and support. As such, an effective security management team should be put into place with assurance that they are properly trained.

It may be possible to assign a single individual to manage the overall security of the IT environment and then give personnel with existing responsibilities, additional responsibilities to support security. IT administrators are often very good choices to support, configure, and administer the security of a system/network, owing to their intimate technical knowledge of the operations and services provided. There are also procedures that ensure that the personnel managing the security of the system/network do not overstep their boundaries (i.e., auditing of events and actions taken).

The following high-level items should be considered during this phase:

• Security Operations and Administration. Operation of a system involves many security activities discussed in this blog. Performing backups, holding training classes, managing cryptographic keys, keeping up with user administration and access privileges, and updating security software are some examples.
• Operational Assurance. Operational assurance examines whether a system is operated according to its current security requirements. This includes both the actions of people who operate or use the system and the functioning of technical controls.
• Audits and Monitoring. To maintain operational assurance, organizations use two basic methods: system audits and monitoring. These terms are used loosely within the computer security community and often overlap. A system audit is a one-time or periodic event to evaluate security. Monitoring refers to an ongoing activity that examines either the system or the users. In general, the more “real-time” an activity is, the more it falls into the category of monitoring.

User Awareness and Training

User training and awareness is critically important to the continued success of any security program. Company insiders either accidentally or intentionally cause approximately 85% of security breaches. Security training instills awareness and enables users to understand the importance of security. In most organizations, security is regarded as required, but not viewed as vital. Most security training material distributed to users is either stuck in a drawer or immediately given away to someone else.

The training program should cover the following “general” types of information:

• Explanation of the security program, its importance, and value
• Who is in charge of the program and specific lines of authority
• Security services, functions, and mechanisms
• Responsibility of the user and management community
• Specific information and information services defined to be sensitive and critical
• The “insider” threat and how to report security incidents
• User and operator errors and how to prevent against these common security problems
• Penalties for security breaches

The most effective way for security training to take root within an organization is for upper-level management to make security an important issue. Once this commitment is made at the higher levels, it will be passed on through the management chain. Migrate from reactive policy, controls and, rules to engage “people” with the skills, knowledge and positive attitude. Empower resources as part of an extended security team to recognize and report potential breaches, issues and/or incidents – provide them the responsibility and accountability to play a role.

Coming Soon!

In future blogs we will cover the Adaptive Security Lifecycle, Identity and Role-Based Access, Application Architecture Taxonomy together with Data Center Trust Zones as key components for the hyper-extended IT enterprise (insourced, co-sourced, managed).

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.

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.

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.

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.

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.

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.

Security Architecture Baseline

Security Architecture Baseline

Once distributed roles and responsibilities are identified and established for the security architecture project team, the next important step is to add to that foundation with a security architecture project baseline.

This blog series will enable organizations to create that baseline by defining and reviewing applicable regulations, security policy and standards, identifying and classifying information assets and resources, and conducting a risk and threat analysis.

It is critical that security policy is aligned with and frames the security architecture, and that risks are assessed, mitigated, and managed on an ongoing basis. The prime objective of the security architecture is to emphasize accountability and share responsibility while enabling business applications and other requirements.

Mission Critical Assets

How much money, inconvenience, and time should an organization spend to counter an exposure or class of exposure? How does an organization deploy defense-in-depth to address and/or mitigate Advanced Persistent Threats (APT)? What is the organization trying to protect? It is very challenging to try to protect everything and anything equally regardless of its role and trustworthiness.

Taking an inventory of all IT infrastructure assets helps identify potential targets. At the rate some companies are growing today, it’ is no surprise to discover unknown active equipment on an internal network. Finding this equipment and determining ownership establishes responsibility and accountability for what occurs on the equipment.

Classification involves assessing what resources or assets an attacker might want to steal. The inventory forms a clearer picture of exactly which data is really critical to the business, and thus which applications and servers need the most protection, monitoring, and auditing. This step lets the enterprise focus its resources and budget at the optimal level on the most significant or sensitive data.

Inventory of Assets

The security architecture project leader coordinates the creation of an inventory of major assets associated with each information system. Each asset should be clearly identified and its guardianship, retention schedule, data categories and security classification agreed upon and documented.

Wherever possible, use E-Discovery or Enterprise Search Tools (crawler, index) to identify assets and sensitive data to reduce the burden of this task and to keep the data as current as possible. The baseline security inventory should encompass, for example, the following assets and data:

• Applications & Systems– (APIs, COTS Applications, Custom Apps, Appliances)
• Structured Information – (DBMS, Databases: Oracle, SQL, etc.)
• Un-Structured Information (E-mail, File Systems, Content Repositories)
• Network-based Storage (SAN, NAS, NFS, etc.)
• Middleware (BizTalk Message Bus, EDI, etc.)
• Server Systems (Mainframe, MacOS, Wintel, Unix, others)
• Hosting & Virtualization (VM Control, VMs, Storage, etc.)
• 3rd Party Services (Service Provider, Cloud,

Developing a security inventory is a necessary step, but it is also the one where most companies get bogged down. Asset self-discovery tools, and strategies that let you group or aggregate assets into organized categories can help considerably.

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) since a set of applications may provide a service or business function. This will be discussed in more detail in a future blog.

Next Steps

In the Security Architecture series blogs, as part of Application & Systems Zoning and Application Architecture Taxonomy series I will share advice on the practical classification of assets taking application and system use cases and applying criteria (user and application roles and relationships) towards organization and protection, i.e., Zone Placement, Zone Policy and Zone Controls based on Risk and Threat Assessment. Simplicity is the path to better security.

Thanks for your interest.

Nige the Security Guy.