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

Security Architecture Series

The Security Architecture Series build upon each other and contains:

APT Defense Strategy Series

APT 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

Security Governance Series

The Security Governance Series contains, as follows:

Security Assessment Series

Security Assessment Series

The Security Assessment Series contains:

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.

Security Organism

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 Lifecycle

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.

Architecture Evolution

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.

Security Governance

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:

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.



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.

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.

Security Drivers

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.

Security Program

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.

Security Plan

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.

Implementation Documents

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.

Security Process

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.

RFI Scorecard

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.

Vendor ComparisonEvaluating 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.

Network Security Evaluation

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

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:


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


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


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


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.


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.