Generated from Enterprise Security Architecture.pdf Automatically

Enterprise Security Architecture Note.md

1. The Meaning of Security

1.1. The Cultural Legacy: Business Prevention

• Security has a bad reputation for getting in the way of real business
• This reputation has developed because of the way security professionals have practised
• We need an accurate definition of what we mean by ‘security’
• A technical definition of security may not be helpful
• Security can be defined only relative to the value and risk propositions of the business

1.2. Measuring and Prioritising Business Risk

• Risk is a combination of asset value, business impact, threat and vulnerability
• Risk management is a combination of risk assessment and ‘risk mitigation’
• The main objective is to prioritise risks so as to make wise control decisions
• Control objectives are the abstract statement of business needs
• Enablement objectives are another type of abstract statement of business need
• Enablement is often the flip side of control
• Security should be business risk-driven

1.3. Information Security as the Enabler of Business

• Security professionals would like to have a positive reputation with their business colleagues
• Your good reputation will depend upon your abilities to serve the business well
• New technologies are impacting the way that business is being done
• The effect is to migrate the point of sale and the point of delivery right into the customer’s premises
• Business-to-business is where most of the initial growth is seen in digital business
• Lack of customer confidence is an obstacle to digital business and eBusiness development
• On-line banking security breaches are very damaging to reputations
• Public relations management is just as important as technical expertise in the protection of reputation
• Scaling and capacity planning are critical issues with respect to service availability
• Electronic government will only succeed if the citizens can have confidence in the correct operation of the systems
• Systems integration is a major challenge in the delivery of legacy back-end services through new frontend portals
• The current environment is a huge opportunity for security professionals to excel
• Technology alone is not enough to produce effective security

1.4. Adding Value to the Core Product

• There are different issues for retail business and corporate business
• ICT is impacting on traditional bricks-and-mortar companies in several ways
• Most traditional industries have similar experiences
• Customer confidence in safety-critical systems is created and maintained through a comprehensive assurance programme
• New ways of working enabled by new technology have a significant impact on customer expectations
• Customer decisions are affected by perceptions of service

1.5. Empowering the Customers

• Customer empowerment means giving the customer choices
• Understanding the concept of customer service is critical to business success in the new economy
• Information security practices can deeply affect perceptions of customer service
• Service quality and information security are closely linked

1.6. Protecting Relationships and Leveraging Trust

• Business relationships are based upon trust
• Trust is a business relationship attribute, not a technical attribute
• Technical systems need to protect the trust that exists in a relationship
• If you trust the source of an information service, you must also be sure that you are talking to the authentic trusted party and not to an impostor
• Trusted third parties act as intermediaries to introduce business partners to one another
• Business relationships are formed in similar ways to social relationships
• Business relationships are driven by human factors, not by technology
• Mutual trust is essential, and must be protected by technical systems

2. The Meaning of Architecture

2.1. The Origins of Architecture

• Architecture is best understood in the context of buildings
• Architecture fulfils the needs of those who experience it
• The needs that architecture must fulfil are very diverse
• Goals, environment, materials and skill are key drivers of architecture
• The Sydney Opera House could not have been built in piecemeal fashion

2.2. Managing Complexity

• A major function of architecture as a tool is to manage complexity in large projects
• Architecture also acts as a road map for a collection of smaller projects that must be integrated into a single homogenous whole
• Architecture provides a framework within which many members of a large design team can work harmoniously
• This is achieved through layering techniques and through modularization

2.3. Information Systems Architecture

• Architecture has been adapted to other spheres of creativity
• Information systems architecture addresses the creation of business computing systems
• Information systems architecture has influences similar to buildings architecture
• Architecture addresses a wide range of issues beyond the technical domain
• An inadequate understanding of architecture can lead to failure to deliver business value
• This book addresses the wider issues, not just the technical dimension
• Business systems architecture is the highest-level framework
• Business architecture is the primary component
• Information architecture is an abstract representation of the business
• Information architecture is the framework for business information management
• It describes information types and their behaviour
• The applications architecture supports the information architecture
• Applications represent and support real business processes
• Modern applications architectures are likely to exhibit certain common properties
• Applications architecture enables business flexibility
• Infrastructure is the logical and physical medium for supporting applications
• Infrastructure architecture is highly technical
• Risk management architecture cuts across all others
• Risk management architecture is pervasive
• Management and governance architecture is all-pervasive
• It describes how the management team controls the business
• Management and governance architecture describes levels of authority and decision making
• Definition of information systems architecture
• Infrastructure is a multi-layered technical architecture
• Service integration is middleware plus data management plus common services
• Data processing means ‘platforms’; Information transfer means ‘network’
• There are three pervasive service types
• ‘Operational services’ means people and the tasks that they perform

2.4. Enterprise Security Architecture

• Many organisations have a long history of piecemeal implementations of security
• The total cost of ownership of multiple systems is often driven by the complexity of the diverse user authentication methods in use
• True architecture never happens by accident
• Enterprise security architecture is the solution to the business problems of piecemeal development
• Business strategy for security is closely linked to operational risk management goals
• The SABSA®model is used in this book as the framework for developing an enterprise security architecture
• Everything in a security architecture must be a reflection of business requirements
• The model is generic and defines a process for architecture development — each solution will be unique to the individual business

2.5. Why Architectures Sometimes Fail to Deliver Benefit – and How to Avoid that Fate

• George Santayana
• The piecemeal approach to security is commonly found
• Far from rendering business benefits, this leads to business problems
• Good security is business-led and business-serving
• Information security is only one part of the business assurance picture
• Availability, integrity, authenticity, confidentiality, accountability, auditability
• Security has to be balanced against other requirements
• Requirements often pull in conflicting directions
• Some requirements are specific to the business of the enterprise
• Security architecture must address the wider range of requirements
• Failure to address the wider range of issues is common
• Successful architecture is business-focused
• Success as an architect requires strength of character and good communications skills
• Senior management buy-in and support is a critical success factor
• Geoff Rob’s Ten Rules for the Solution Architect

2.6. Security Architecture Needs a Holistic Approach

• Security can be analogous with a chain — one link breaks, the chain is broken
• Complex systems have a holistic design quality and are not described by checklists alone
• Complex system example
• Checklists often miss out key questions
• You need a holistic approach

3. Security Architecture Model

3.1. The SABSA® Model

• Continuing with the analogy of building architecture
• The architecture model used in this book has six layers
• The layers can also be arranged so that Operational Security Architecture is a vertical bar
• Kipling’s poem provides six key questions
• Before an architect can begin work the business owner has to specify what sort of building is needed
• Five more key questions
• what
• Understanding requirements is a prerequisite to effective design
• We take a similar approach in developing an architecture for a secure information system
• By asking these questions you establish the business requirements
• The result is the contextual security architecture
• contextual security architecture
• Shortcuts that omit this step are likely to result in failure to meet business needs
• Technologists are traditionally not good at listening to the business owners and users
• It is not uncommon for an information systems group to have a poor relationship with business colleagues
• Following through all the layers in the architectural model is essential to success
• Each layer is also analysed vertically using six key questions

3.2. The Architect’s View

• An architect is a visionary who creates the concept of how the system will be built, and sets the design rules
• The architect’s view is the conceptual security architecture
• concept
• Once again one needs to ask the six key questions for the vertical analysis
• What? — Business Attributes
• Why? — Control Objectives – the motivation for security
• How? — Major security strategies and layering principles
• Who? — The security entities and their trust relationships
• Where? — The security domain model
• When? — The time dependence of security

3.3. The Designer’s View

• The designer must realise the architect’s vision as a meaningful design
• The process is known as ‘systems engineering’
• system
• The result is the logical security architecture
• As for the other layers, six key questions reveal the vertical analysis

3.4. The Builder’s View

• The builder constructs the physical system
• This view is called the ‘physical security architecture’
• The six key questions again

3.5. The Tradesman’s View

• The construction process needs a range of different skills and component parts
• Construction requires the integration of many components
• The component security architecture
• Once again the six key questions

3.6. The Facilities Manager’s View

• The facilities manager runs the building in its operational lifetime
• The operational security architecture
• Operational security architecture cuts across the other layers

3.7. The Inspector’s View

• Providing assurance through audit and inspection
• An integral part of the operational security architecture

3.8. The SABSA® Matrix

• The six key questions that have been asked at every layer to provide a vertical analysis
• The overall framework is the 36-cel1 (6×6) SABSA®Matrix

3.9. Detailed SABSA® Matrix for the Operational Layer

• The operational layer also maps over the other five layers

4. Case Study

4.1. Intergalactic Banking and Financial Services Inc

4.2. Interviews at IBFS

• years

5. A Systems Approach

5.1. The Role of Systems Engineering

• Systems engineering is ‘A rational approach to decision making related to the solution of complex problems in engineering planning, design and operation”
• Systems engineering is the most relevant approach to designing digital business systems
• rational approach to decision making related to the solution of complex problems in engineering planning, design and operation
• The aim here is to apply systems engineering thinking, not to reinvent systems engineering
• SSM has been ill served by its commentators, many of whom (sic) demonstrably write on the basis of only a cursory knowledge of the primary literature
• The description here is a high-level summary of the systems approach
• Systems engineering practices are useful tools for the security architect

5.2. Why a Systems Approach?

• Complexity is a primary issue
• Top-down decomposition of the system into sub-systems enables complexity to be transformed into simplicity
• The ‘black box’ concept is another aspect of systems decomposition and analysis
• Black boxes take an input and transform it into an output
• Black boxes assist in creating simplicity from complexity
• Systems can be analysed into a logical flow through a series of black boxes
• A systems approach provides a structured framework in which to work

5.3. What Does the Systems Approach Make You Do?

• Write down what you really need
• to write down what you really need
• If you can’t write it down, you haven’t thought it through
• if you can’t write it down, you haven’t thought it through
• ‘Writing down’ includes both diagrams and text
• Structured review and feedback is a peer-review process
• Communication and preservation of ideas

5.4. The Need for Systems Engineering in Security Architectures

• Systems engineering addresses complex problems
• Modern business systems are becoming more and more complex
• Complexity is destabilising unless you have tools to manage it
• Systems engineering techniques provide the tools for managing complexity

5.5. Some Basic Concepts

• The system seen as a collection of component parts and actions
• System objectives should be mapped to business requirements
• Starting with only technical objectives is a common fault
• Incorrect objectives lead to poor solutions
• The system environment is outside of your control, but you must consider its influences
• influence
• System resources are within the system boundary
• Top-down decomposition into nested sub-systems reduces overall complexity
• Sub-system design must take account of overall system goals
• Management implies the ability to measure
• Management is concerned with ensuring that the objectives are met
• ‘Performance’ here has a wide meaning
• Business Attributes provide a technique for normalising objectives and measuring performance

5.6. The Control System Concept

• Control loops are used in control systems
• Feedback control is the most common
• A feedback loop is constructed from three basic sub-systems
• Measurement information is fed back through a decision module to a control module
• Control loops are used to manage security in business systems

5.7. Using the Systems Approach in Security Architecture

• A systems approach helps in the design of secure systems
• Use broad business-based definitions of objectives
• Always include the environmental elements
• Threats are environmental; vulnerabilities are within the system
• Use decomposition into subsystems to reduce complexity
• Meaningful monitoring and measurement is the key to successful system management
• meaningful

5.8. Case Study

• all
• all

5.9. Advanced Modelling Techniques

• Advanced techniques for those with a deeper technical interest
• Business process engineering applies system concepts to business
• Certain processes are common to many enterprises
• A meta-process is used to manage processes
• Business process engineering uses top-down decomposition
• Business process engineering leverages new technology
• Business processes are built up from individual functions
• Business processes need to be managed at a process level, not just a functional level
• Higher-level systems depend on their constituent lower-level components
• The AND relationship
• The OR relationship
• AND increases risk; OR decreases risk
• Can be applied to sophisticated risk modelling
• Traffic light systems have finite states
• Finite state machine is another system modelling tool
• The model comprises states, state variables, state transitions and events
• All of the finite number of states must be identified
• all
• Predicates govern the selection of the appropriate outgoing event
• Specific actions are local responses to incoming events
• FSMs behave atomically
• FSM modelling is applied to interactive protocols in systems
• Security architectures embody many interactive protocols
• FSM modelling is a tool for guaranteeing high levels of assurance in systems
• Types of high-assurance system
• High levels of assurance require comprehensive model checking and possibly formal specification languages
• This section offers a brief introduction to FSMs, not a comprehensive treatment of the subject
• New security-specific techniques such as trust modelling and domain modelling will be introduced later in the book
• Systems Engineering
• Systems Thinking Systems Practice
• Systems Engineering

6. Measuring Return on Investment in Security Architecture

6.1. What Is Meant by ‘Return on Investment’?

• Return on investment is concerned with evaluating the payback
• Insurance is not a good analogy for security
• If security is good, there are no incidents — nothing happens — which makes it hard to demonstrate benefit
• ‘Return of value’ is perhaps a more useful phrase

6.2. Why Do You Need Metrics?

• Some famous quotations about measurement
• The ‘can’t measure, can’t manage’ maxim from Drucker is especially useful
• Many people need measurements
• The information security manager needs measurements
• The team members need measurements
• Senior managers need measurements
• Measuring security performance can be challenging. The SABSA®Business Attributes Profile provides a useful approach

6.3. The Security Management Dashboard

• The concept of an instrument panel or dashboard is useful
• The measurements and the reporting of them is an important element in feedback control loops
• The dashboard provides the means to assess the status of the security management process
• The domains of activity follow accepted wisdom
• Success depends upon diligence in all three domains
• There are a number of ways to provide the measurements

6.4. The Balanced Scorecard Approach

• Balanced Scorecard is a general business performance measurement methodology
• BSC combines financial measurements with other more qualitative methods
• BSC translates strategy into performance measures
• There are four perspectives for the measurements
• The four perspectives form a layered architecture model
• Here are some of the benefits of using BSC
• BSC is the first step towards becoming a Strategy-Focused Organisation
• Strategy-Focused Organisations operate on five principles
• BSC is highly suited to new strategies and organisational alignment
• There is considerable harmony between BSC and the aims of a security architecture programme

6.5. Business Drivers and Traceability

• Which of the many possible metrics that could be displayed on the dashboard should you choose?
• If security is difficult to measure, risk may be easier
• Risks tend to be the negative side of Business Attributes
• Business drivers for security are closely related to these Business Attributes
• Business drivers are part of the contextual security architecture
• A layered architecture approach gives bi-directional traceability
• This layered framework ensures that every component and every operational procedure is there because at the top of the model there is a business driver that eventually is satisfied by these elements
• Every solution is traceable back to and justified by some business requirements

6.6. Business Attributes and Metrics

• The taxonomy of Business Attributes is based entirely on practical experience
• New Business Attributes are added as experience grows
• The taxonomy is classified under seven headings
• Business Attributes can be used in one of two ways
• A one-to-one mapping between Business Attributes and business drivers is not a necessity
• Traceability is derived from the cross-mapping of Business Attributes and business drivers
• The actual metrics you use must fit into your specific business model
• There are hard, quantitative metrics and soft, qualitative metrics

6.7. Setting Up a Metrics Framework

• Having selected the Business Attributes, you need to select your measurement approach
• Further examples
• The metrics provide the means to monitor ongoing performance of the security management programme
• Independence of the reporting should be preserved

6.8. Maturity Models Applied to Security Architecture

• Capability maturity models have been developed at Carnegie Mellon University
• CMM uses a domain structure called Process Areas
• CMMs have been developed in several application areas
• The CMM concept has also been developed for system security engineering
• The SSE-CMM uses both Capability Levels and Process Areas
• Definition of a Process Area
• Definition of a Base Practice
• Tables show examples of the practices used in SSE-CMM
• The CMM concept is very good, whether or not you use this specific version of it
• CobiT is an open standard for the IT Governance Institute
• The CobiT Management Guidelines
• CobiT Key Indicators
• The CobiT CMM
• ad hoc
• The CMM is used to benchmark the enterprise
• Visual presentation of the benchmarking results
• A CMM can be used directly to report progress to senior man
• Using a CMM requires some sophistication on the part of the management team
• It is not always appropriate to aim for the top of the scale
• Benchmarking measures performance against an external standard
• You need self-assessment for benchmarking
• The benefits of benchmarking play to your need for measuring return on investment

7. Using This Book as a Practical Guide

7.1. Using the SABSA® Model to Define a Development Process

• The SABSA®Model previously introduced is the basis of the development process
• Development is sequential, except for the operational layer
• There is a natural sign-off and buy-in milestone after the conceptual layer
• The design phase follows the sign-off and buy-in milestone
• Completion of the design phase is another major milestone
• After implementation comes the manage and measure phase
• The four phases form a cycle – an architecture lifecycle
• Each phase is described in detail below

7.2. Strategy and Concept Phase

• The diagrams show the detailed processes
• You begin by collecting business requirements
• The business requirements populate the first row of your architecture matrix
• The format as a row in the matrix is for presentation only — the information is physically held in a series of working documents
• ad hoc
• By analysing and synthesisingyou create the deliverables
• Detailed flow charts of activity are shown in the diagrams
• The process diagrams are arranged in columns
• Off-page connectors indicate the linkage to other flowcharts
• The flowcharts show key input sources
• The Business Attributes Database is applied twice
• The Threats Database prompts your thinking on risk assessment
• Fitting together the two layers of this phase
• The assets of the business are conceptualised in the Business Attributes Profile
• The success factors and mitigation of risks are conceptualised as control objectives
• The entire business model drives the security strategy at the conceptual layer

7.3. Design Phase

• Design only begins when you have sign-off to the Strategy and Concept phase
• Sometimes your work must begin somewhere in the middle of the process, utilising earlier work that precedes it
• If you have to start in the middle, you should validate previous work
• The design authority takes responsibility for the integrity of the design
• The detailed development process is shown in the flowchart
• The business information model is a prerequisite
• The business process model is a prerequisite
• A functional specification is part of the logical architecture
• Functional specifications are usually associated with specific projects
• Where future projects conflict with the architecture, a resolution process is needed
• The detailed flowchart shows the development process
• The detailed flow-chart shows the development process
• Operational people must be involved in designing the operational security architecture
• At this stage you develop only the framework for the operational processes
• Further insight into how it all fits together
• Case study example on directory architecture

7.4. Implementation Phase

• Infrastructure projects rarely get business support
• Enterprise-wide security architecture will never be implemented as a single project
• Implementation of architecture is fragmented — one project at a time
• Architecture governance is needed to ensure that projects comply
• The detailed flowchart shows the implementation process

7.5. Manage and Measure Phase

• Manage and Measure is concerned with operational aspects
• Operational costs are usually the greatest contributor to total cost of ownership
• Measurement is required to feed back to senior management the success story
• The detailed flowchart shows the management and measurement process
• Security architecture must live and breathe — it changes over time

8. Managing the Security Architecture Programme

• Now that you know how to say it, what do you want to say?
• Identify specific business problems in your organisation and explain how you can help to solve these problems
• Build a return on Investment model specific to your organisation
• Leverage the fact that senior management already understands economies of scale
• Remind the directors that you are protecting their personal liabilities under the law

8.1. Selling the Benefits of Security Architecture

• You need to sell your programme to the senior management team
• How sell an idea and influence opinion
• These rules for communicating are unfamiliar to those with a traditional scientific education
• A successful security architect applies these rules in many different ways
• Appeal to the senior management focus on overall business risk management
• Diligent risk management is part of good corporate governance
• Internal auditors have different roles in different organisations
• Emphasise the benefits of being well-prepared for the internal auditors
• Extend the idea to preparing for the external auditors
• The business analysts are very powerful influencers
• Analyst opinion affects share price, which is critically important to senior management
• Quote the analyst reports to support your case
• Fast time to market is often an important business driver
• Security architecture helps to promote a fast turnaround on projects
• Common security services and mechanisms are the key success factors
• Development speed must also be traded against assurance – security architecture helps here too
• Frequent business reorganisation is commonplace
• Monolithic security architecture presents an obstacle, but domain-based security architecture makes reorganisation easy to manage
• Security domains are a key concept of the methodology
• Operating costs usually dominate the overall cost model
• Look out for places where there are high operating costs and where the security architecture can provide large cost savings
• Statistics on how long it takes to resolve user problems are often available
• Use the available statistics to assess how much productive time is lost through user problems
• Make sure the security architecture specifically addresses these productivity losses
• The concept of a standardised desktop configuration is often used to optimise the help desk efficiency
• Outsourcing ICT operations, including certain security management operations, is popular
• Outsource the operational implementation of security policy — not the setting of security policy
• Design the security architecture keeping in mind an outsourcing strategy for security operations
• Cost saving has already been identified in earlier discussions
• Make sure you identify the potential cost savings specific to your organisation
• Trust is an attribute of relationships. Technical systems are used to protect that trust
• already
• Business is based on trust. Electronic and digital business also need to support and protect that trust
• Key security services are used to provide this protection of trust
• The login process is often a source of major frustration through inconsistencies in the user experience
• Standardising the login user interface is one of the major benefits of a security architecture
• Single sign-on offers the most efficient login interface but is controversial with regard to its vulnerability of a single password
• Although multi-factor authentication can solve the technical vulnerability of a single password, it still raises many other significant issues

8.2. Getting Sponsorship and Budget

• Getting sponsorship depends upon being able to sell the benefits to budget holders
• Key influencers of budget holders are also a good target for you
• Here are some points that might help to persuade those whose support you seek

8.3. Building the Team

• The security architecture programme is a team game
• Definition of a team
• Belbin’s research into team roles provides a very useful model
• Research shows that teams based objectively on these roles are more successful than those selected by subjective intuition
• Subjective selection of team members does not usually produce the right mix of skills
• Examples of poor team configuration are common
• In knowledge-based working, team members must be empowered and must buy in to the team objectives
• Empowerment must include some risk-taking and incorporate a tolerance of mistakes
• Team development has four identifiable phases
• Effective teams have certain characteristics
• Team dynamics are nothing new, but they will impact the success of the security architecture programme

8.4. Getting Started: Fast Track™ Workshops

• Getting everyone started and ensuring their buy-in can be challenging
• You could use this book get everyone to read it!
• The authors have successfully used Fast Track™ workshops to overcome this challenge
• Fast Track™ gets the key players to experience every aspect of the programme in a short time
• The workshops are based on small syndicate groups
• Each topic is treated in turn
• Some types of people such as senior managers attend only a restricted subset of the workshops
• Every Fast Track™ is tailored to the specific needs of the client organisation
• There is a post-workshop report that summarises the output from the workshops
• The objective of Fast Track™ is to create a realistic programme plan
• If you want to explore this approach, please make contact

8.5. Programme Planning and Management

• Professional programme and project management is an essential ingredient for success
• Being a good team leader does not necessarily imply good project management skills

8.6. Collecting the Information You Need

• You will need to collect certain information about the organisation
• Collecting information on the business is critical to the SABSA®process
• You need to get access to the most senior managers that you can reach
• Use a senior champion to help secure the interviews with the right people
• A senior management interview is a great opportunity
• It also carries some risks
• Here are some ideas on the types of questions to use in a senior management interview
• Some questions can be very sensitive
• The questions here will provide you with a general idea of the type of approach to take
• Encourage an open response
• Validate your understanding of the information provided
• Executives and managers can have conflicting requirements
• Understand the best way to record interview results
• The skill of the interviewer is critical — make sure you use on-the-job training to develop these skills
• Some senior interviewees can be quite hostile
• Existing documents and reports can be a good source of material, especially the annual report and accounts
• Other existing documents are also potentially very useful
• In your organisation there will be other specific sources that you can identify
• Technical information is relatively easy to collect
• The relationship with technical managers is also significant in getting agreement about solutions

8.7. Getting Consensus on the Conceptual Architecture

• You will need to gain consensus on the conceptual security architecture
• The clear division of lifecycle phases is to emphasise this point
• You must build and maintain strong relationships with the key players
• Find out what makes them tick
• Foresee difficulties and manage expectations
• Gain consensus through open forum workshops
• Pre-selling the ideas ensures success at the workshops
• Politics and diplomacy are necessary to your success

8.8. Architecture Governance and Compliance

• Security architecture is a strategic road map that should be followed by all projects
• To be successful, there must be a way of ensuring that all projects comply with the architecture
• Controlling budget sign-off is a good tool to ensure compliance
• The Architecture Board is the mechanism by which compliance is governed
• The Architecture Board approves the architecture and approves projects as being compliant
• Here are some ideas on membership of the Architecture Board
• A possible substitute for the Architecture Board is an ISO17799-style steering committee
• The Design Authority is a single person accountable to the Architecture Board for compliance of a given project

8.9. Architecture Maintenance

• Despite the durability of an architecture, changes will be needed
• Business requirements change over time
• New technologies emerge and need to be integrated because of new benefits they bring
• Practical operating experience also exposes flaws and suggests new approaches
• Architecture maintenance should be under the governance of the Architecture Board

8.10. Long-Term Confidence of Senior Management

• You must maintain the momentum of senior management support
• No flow of deliverables will lead to loss of confidence
• Manage expectations
• Management Teams
• Teamwork
• Psychological Bulletin

9. Contextual Security Architecture

9.1. Business Needs for Information Security

• SABSA®Matrix cross-reference
• ICT has become pervasive in modern businesses
• The value of information security is related to the business value protected
• This chapter provides a list of important things to investigate
• Business drivers identified in this chapter are the primary inputs of the SABSA®Methodology

9.2. Security As a Business Enabler

• SABSA®Matrix cross-reference
• Information security can enable business that would otherwise be too risky
• Electronic publishing needs security to protect against unauthorised copying
• On-line music and movies also need protection against theft of the material
• All digital entertainment media have this requirement
• Restricting access to a value added service makes it a commercial proposition
• Electronics is widely used in process control
• Once the control is removed to a remote location, security becomes an important issue
• You do not have to run a factory to have remote process cortrol issues
• Network management is a case of remote process control
• Many network management systems have a very poor level of security
• Large businesses are often dependent upon successful management of the supply chain
• ICT is frequently used to improve supply chain management
• Where It is applied, there are many security issues to address
• The Internet and the web are frequently used for research purposes
• Trust in the sources of information is an issue
• Authentic service providers who charge for services need to protect their revenue

9.3. Digital Business

• SABSA®Matrix cross-reference
• ‘Digital business’ is post dot-com terminology
• ‘Digital business’ defined
• The lifecycle of the dot-com rise and fall
• Reasons for the dot-com phenomenon
• What you need to do next to recover after the dot-com crash
• Enterprise security architecture is part of the recovery process
• Banking has been an early adopter of information and communications technology for many years
• Banks are also very experienced in the deployment of information security
• There are always new exploits emerging
• Important message to all customers
• Please read this important message about security. We are working very hard to protect our customers against fraud. Your account has been randomly chosen for verification. This is requested to us to verify that you are the real owner of this account. All you need to do is to click on the link below. You will see a verification page. Please complete all fields that you will see and submit the form. You will be redirected to the IBFS iBank home page after verification. Please note that if you don’t verify your ownership of account in 24 hours we will block it to protect your money. Thank you
• Electronic purchasing is a popular application with many benefits
• The main benefit is bringing rogue buying under control
• Fraud prevention is the main security focus
• eGovernment should provide better service to the citizens
• There are also concerns about government exerting too much control over citizens
• There are many security requirements for successful eGovernment

9.4. Operational Continuity and Stability

• SABSA®Matrix cross-reference
• Revenue generation depends upon operational continuity
• ICT has been applied to improve customer service levels and to make customer service into a competitive issue
• If you raise expectations of customers, you must deliver to those expectations
• If customer service is a key differentiator, it is worth protecting
• Reputation is difficult to measure
• Operational incidents do impact on reputation, but how much?
• Reputation failure is unpredictable — so you must limit the risks that you take with it
• Protecting reputation is an individual thing
• Management information helps you to keep control of your business
• Management information needs to be accurate and timely
• Some regulated industries require an operating licence
• Regulation is a strong business driver for information security
• In organisations where the employees are key to success, you need to maintain their confidence
• Professional employees are tuned into management performance, including security management
• Employees need to feel trusted and empowered to do their work
• Employees must be protected against personal abuse and false accusations
• Personal privacy in the use of corporate systems is a sensitive issue
• Reasonable personal use of corporate systems is probably a wise middle ground to seek out
• Shareholders have several windows through which they see the workings of the organisation
• Corporate governance is an issue for shareholders
• Satisfying the auditors and analysts is the key to maintaining shareholder confidence
• Some organisations do not have shareholders
• Government organisations are susceptible to sweeping changes reflecting political policy changes

9.5. Safety-Critical Dependencies

• SABSA®Matrix reference
• Safety-critical systems defined
• Hacking into remote communications to safety-critical systems is a major security issue
• Applied cryptographic techniques provide a large part of the solution
• Authentication of communications to a remote safety-critical system is a particular requirement
• Authentication of support documents in the civil aviation industry is also important to prevent all methods of logical attack
• Assurance of correct working is a key requirement for safety-critical systems
• The main issue is assurance of no unwanted functionality
• Security of safety-critical systems has demanding requirements

9.6. Business Goals, Success Factors and Operational Risks

• SABSA®Matrix cross-reference
• Brand is one of the most valuable assets of any organisation
• Fraud is nothing new but there are new ways to commit fraud
• Computer systems can be a means to commit fraud
• ‘Computer fraud’ is committed by people, not computers
• There are many operational risks that can lead to business losses
• Business continuity management requires security management of systems to ensure continuous service
• Business continuity is a key business driver for the information security architecture
• Security architecture supports strategy
• Business strategy calls for good governance and accountability
• Legal factors are another major business driver for information security architecture
• The Business Attribute Profile will help you to identify the relevant legal drivers
• Every business has many key stakeholders
• Maintaining stakeholder confidence is a key driver for your security architecture

9.7. Operational Risk Assessment

• SABSA®Matrix cross-reference
• Operational risk defined
• Risk assessment is needed for the contextual security architecture
• To assess risk you need a suitable model
• Estimating the likelihood of an event is complex
• Risk assessment is an important part of the methodology in this book
• Quantitative threat assessment is unrealistic for most organisations
• Intelligence gathering is also unrealistic for most organisations
• Vulnerability assessment is much more realistic
• A typical risk assessment method
• To understand threats you need a modelling framework
• A taxonomy of threats is included to help you
• The first dimension is the threat domain, based upon the definition of operational risk
• The classification scheme has two dimensions
• The domains explained and described
• The second dimension is the threat category, based on experience and observation
• To gain greater insight into threats you can construct threat scenarios
• The main reason to do risk assessment is to identify the most important risks in order of priority
• A qualitative method of risk assessment is described here
• Risk mitigation is the process of setting control objectives and implementing controls through the security architecture
• This is a key contextual/ conceptual interface

9.8. Business Processes and Their Need for Security

• SABSA®Matrix reference
• Interactions require identification, authentication and authorisation
• Methods of communication have an important effect on your security architecture
• The applications also drive the security architecture
• You need to look at threats, impacts and vulnerabilities for each form of communication
• There are many forms of electronic business transactions
• You need to examine your transactions to define your security reuqirements

9.9. Organisation and Relationships Affecting Business Security-Needs

• SABSA®Matrix cross-reference
• Organisational drivers for information security

9.10. Location Dependence of Business Security Needs

• SABSA®Matrix cross-reference
• The Internet has made business much less dependent upon relative location of the players
• Many people now work from remote locations
• Virtual teams are spread across the world using ICT to communicate
• Data networks connect distant physical offices into a single logical office
• Some virtual companies have no office at all
• More business drivers

9.11. Time Dependency of Business Security Needs

• SABSA®Matrix cross-reference
• To attack a secure system takes time
• To detect an attack and to react takes time
• Time Based Security

10. Conceptual Security Architecture

10.1. Conceptual Thinking

• Conceptual architecture is about being able to design the forest rather than the trees
• Conceptual architecture is about the big picture
• This book is designed to help you be a successful security architect

10.2. Business Attributes Profile

• SABSA®Matrix cross-reference
• The taxonomy of Business Attributes captures many years of practical experience
• Business Attributes are used in two different ways
• Your Business Attributes Profile is a conceptual representation of your business
• The Business Attributes Profile is a powerful tool
• The Business Attributes Profile is an important part of your conceptual security architecture
• The Business Attributes Profile provides the target for the measurement phase
• This integrates the Manage and Measure phase with the Strategy and Concepts phase

10.3. Control Objectives

• SABSA®Matrix cross-reference
• Control objectives state the desired result of implementing controls
• Control objectives can be generic good practice or specific to a business need
• Control objectives conceptualise the Business Risk Model
• The control objectives form an interface between the contextual and conceptual layers
• There are several sources of generic ‘good practice’ control objectives
• The control objectives form a core part of the conceptual security architecture

10.4. Security Strategies and Architectural Layering

• SABSA®Matrix cross-reference
• There are many approaches to layering and security strategy
• Security architecture is not the same as software architecture
• Increased effectiveness is achieved by multiple layers of security of different types
• Multi-layering of security avoids any single point of failure — if one control fails, another will be effective
• Improved effectiveness is also achieved through multitiered security services
• A comprehensive list of security service is inChapter 11
• You need some security infrastructure to support security services
• The infrastructure architecture should be layered
• Network and platform security is distinct from application security
• The distinction of security domains for networks and platforms supports an outsourcing strategy
• To facilitate integration of real-world components you need a common security services API architecture
• The API model is purely conceptual
• To make this API model work, the software architecture itself has to be properly designed
• This requires some in-house development
• This approach allows the integration of components from many different vendors
• Third-party applications are integrated using an application adaptor
• Application adaptors are software modules that provide a conversion interface
• Common security services are integrated as if they were applications
• Applications security architecture is a specialist area
• Legacy applications are often constructed on a stovepipe architecture
• The ‘stove-pipe’ architecture arises through lack of planning and coordination
• This stovepipe approach makes integration difficult
• Modern architectural thinking leads to the daisy model of application architecture
• The ‘daisy’ architecture concept is well-aligned with providing common security services
• Which security services are appropriate at which layer?
• Application security is about authorisation
• You need an authorisation process
• Logical access control enforces authorisations Front-end authentication
• Back-end audit trails
• Security administration for creating and editing
• The Six As of application security
• Legacy systems are often self-contained and difficult to integrate
• An integrated application security architecture has major benefits
• Role-based access control is a conceptual approach needed to deliver these benefits
• Application level communications
• Network security and applications communications security are not the same thing at all
• Network security protects network resources; application security protects application resources
• There is widespread use of data encryption in network layers
• Middleware organises the logical service view of a distributed system
• Explicit security services — called explicitly by the application through an API
• The application may need to receive a result for its
• Implicit security services — provided by the middleware transparently to the application
• The middleware has physical location knowledge and can apply location-dependent context rules
• Middleware security services are provided independently of any other layer
• Explicit security services are called through the common security services API
• There may be constraints on implementing the middleware security architecture due to lack of functionality in vendor products
• Middleware security requires cross-platform inter-operability
• Data management has its own special security requirements
• Data management must implement authorised (controlled) access to data
• Data management subsystem security services
• Data management subsystem security management services
• Information transfer (network) sub-layering
• Network management embraces the managing of security services in the network
• Network security is not there to protect applications or their data
• Separation and independence of application security and network security is the best architectural approach
• These segregation concepts are controversial
• The VPN concept provides limited protection of confidentiality of data being transported
• Other types of protection beyond confidentiality of data are not possible in the network layer
• Network layer security mechanisms have limited value
• Confidentiality services at the network layers suffer the residual risk that the application is unaware if the encryption is turned off
• Network security strategy has many facets
• Processing layer refers to platforms
• Platforms also have operating systems
• Principles of platform security
• Platform security services
• Generic access control subsystem architecture
• Access control decision making process
• Integrated access control in many legacy systems creates architectural problems
• A strategic role-based access control architecture can alleviate these problems
• The use of roles decouples users from target applications for the purposes of administration
• CAM decisions
• CAM enforcement
• system decisions
• Target system enforcement
• RBAC brings many benefits
• Remote communications between the distributed parts of the RBAC subsystem is protected by cryptography
• User-to-machine interaction is also decoupled from the network communications to the authentication server
• Network transmission of passwords is replaced by cryptographic authentication exchange protocols
• Decoupling has the added advantage of architectural flexibility for future upgrades
• Two-factor authentication with token devices can be used to strengthen the user-to-machine interaction
• Biometrics offers some interesting possibilities but is immature and controversial
• Managing security services
• Securing management services
• The TMN model for service management architecture
• TMN is in harmony with the SABSA®approach
• Other standards for service management architecture
• Systems assurance defined
• Cross-reference toChapter 17
• Tools used to develop high assurance
• Cross reference toChapter 9
• Directory service is one of the common security services in the example of security infrastructure architecture
• Directory objects
• Directory functions
• Directory access control
• Directory integrity and availability
• Directory security management strategy
• Important management issues for directory architectures
• Directory object types
• Entity classes
• Directory schema
• User-class attributes
• Using security equivalence for ease of administration
• Users with multiple contexts require multiple user-class objects
• Directory structure and objects
• PKI will have its day again
• We shall describe only the basic principles
• What public key cryptography provides
• Digital signatures
• Public key encryption
• Non-repudiation requires a trusted third-party arbiter
• Conditions for the scheme to work
• PKI defined
• PKI strategy for the future

10.5. Security Entity Model and Trust Framework

• Security entities defined
• Security entities as subjects
• Global unique naming of entities
• The directory as repository for entity information
• Entity relationships
• Trust in entity relationships
• Trust in the merchant-customer relationship
• Two-way trust
• Buyer trusts merchant
• Merchant trusts buyer
• Trust is a relationship attribute, not a technical attribute
• Levels of trust are variable
• If trust can be sold as a service, who is the customer?
• trust broker
• Specific examples show the way
• Buyer trusts claims of quality
• Seller trusts good faith on payment method
• Trust implies a claim by one party that is relied upon by the other party
• One-way trust is the lowest common denominator of all trust relationships
• Real business relationships imply complex two-way trust — which can be analysed into simple components
• Looking for solutions for protecting trust
• PKI plays a part
• The relying party is the customer for trust broker services
• Trust brokers must offer liability cover to add value
• liability
• Original academic models of trust services were flawed
• Trust services have to be based on a true business model
• Trust broker services must meet the needs of the relying parties
• The trusted transaction as the unit of ‘product’
• trusted transaction
• The credit card analogy shows how it should work
• The services on sale are trust and liability management
• trust
• There may be a registration fee
• The relying party wants assurance from the trust broker of trust in a given claim by a claimant
• Transitive trust
• transitive trust
• Transitive trust can be reduced to a series of simple one-way trust relationships
• Pricing and service packaging are commercial
• E-mail trust services are more likely to be subscription services
• Analysing a business application to determine the trust services
• Trust service providers need to understand their market
• Authorisation certificates provide a mechanism for trust brokers to communicate their trust
• Managing the lifetime of authorisation certificates is a business risk-driven issue
• Total real-time risk exposure can be monitored
• Real-time authorisation addresses several architectural issues
• Multiple trust brokers
• Chains of trust
• chain of trust
• Identrus — the solution adopted in the banking industry
• Variable levels of trust
• Strength of registration process is the key to trust
• Low assurance registration
• High-assurance registration
• Verifying credentials often involves transitive trust
• The relationship between level of trust and registration strength
• Different levels of trust leads to different classes of digital certificates
• The market for trust levels is still emerging

10.6. Security Domain Model

• SABSA®Matrix cross-reference
• The security domain concept is very powerful
• Security domains defined
• Security element
• Security policy and security policy rules
• Security policy authority
• Isolated security domains
• isolated
• Independent security domains
• independent
• Agreements between independent domains
• Sub-domains and superdomains
• sub-domain
• Trusted entities in a domain
• Conditional and unconditional trust
• unconditionally trusted
• Trust is not necessarily two-way or transitive
• Secure interaction rules
• Agreed security services, security mechanisms and security information
• Policy relationships in subdomains
• Security association defined
• Logical domain defined
• Separation of logical domains by logical mechanisms
• Physical domain defined
• Separation of physical domains by physical mechanisms
• Domain overlays are possible
• One logical domain can span several physical domains
• Many logical domains can share a single physical domain
• How to apply the domain modelling tool to real situations
• Digital business means opening up the enterprise
• The fortress mentality is an age-old security model
• Many legacy business systems have an eggshell model of security
• For digital business you need something different from the eggshell approach
• The first step is to put a gate in the hard perimeter
• You need a more sophisticated view of trust on a continuous scale
• A binary access control decision is not sufficiently sophisticated for a digital business environment
• You need a much more flexible model for access control
• The honeycomb concept
• The egg and honey combination model
• Multi-tiered security domains
• Hierarchical filtering
• Eggshells are usually physical domain boundaries
• Honeycombs are usually logical domain boundaries
• The overall access control strategy is a combination of the eggshell and honeycomb approaches
• Eggshell maps to network security and honeycomb maps to application security
• Use these concepts to model your business
• Using these techniques helps you to create simple models representing highly complex environments
• VPNs are useful but are not the solution for every problem
• VPNs are constructed using encryption of the transmitted data stream
• An open pipe interconnecting two domains forms a single domain
• To segregate the domains you need to regulate the flow in the pipe
• VPNs are frequently built between firewalls using IPSec technology
• A VPN tunnel through a firewall can be built but has disadvantages
• For extranet VPNs, the VPN client resides on the PC
• A firewall is a network security gateway
• Firewalls have limitations that are not always well-understood
• The corporate domain is an island in the Internet sea
• The firewall alone is ineffective — you need a good security perimeter, too
• The remainder of the perimeter is mostly cultural
• You also need a clear firewall policy
• The firewall configuration needs proactive management

10.7. Security Lifetimes and Deadlines

• SABSA®Matrix cross-reference
• Fixed lifetimes prevent accumulation of dormant registrations
• One to three years is a typical lifetime
• Digital certificates must also be expired
• Certificate life is less than registration life
• Expiry is checked as part of acceptance of a certificate
• Cryptographic keys must be limited in their exposure to cryptanalysis
• Signature keys are retired from use, but previous signatures may still need to verified
• Lifetime depends on security policy
• Cryptographic keys may be archived for data recovery, implying an extended lifetime
• Policy decays over time and needs renewal
• Policy should stable between renewal times
• Rules to implement policies may need to change frequently.
• Passwords should be expired according to the security policy of the domain
• Minimum lifetimes should also be applied to passwords
• History files of previous passwords may be implemented
• Issuing physical tokens is logistically demanding
• Frequent redistribution needs to be avoided
• Token issue should be
• Undeliverable messages have to be managed
• Time to live determines when delivery attempts are abandoned
• Actions on expiry of time to live
• Data storage should have a defined lifetime
• Storage lifetime may apply to each phase of storage
• Archiving lifetime for backup data
• Continued support for reading long-term archived data
• Secrecy lifetimes depends on business need and policy
• Solutions must be selected with long-term secrecy requirements in mind
• Limiting user session lifetimes prevents hacking opportunities
• System sessions are used to limit exposure of cryptographic keys
• The session lifetime determines the key renewal period
• Dial-up session lifetimes are determined by connection lifetimes
• Response time-out manages the problem of undelivered messages or responses
• Time-out values depend on policy
• Care is needed if messages have been actioned but acknowledgement fails
• Inactivity time-outs deal with user carelessness
• Hacking opportunities are reduced by inactivity time-outs
• Actions on a time-out
• The action chosen depends on circumstances
• Time-out values are a policy matter
• Time of day, day of week can be used to set access control contexts
• Context rules can be local or central, depending on policy
• Replay of previous messages can be a serious attack scenario
• To prevent message replays, trusted time stamps can be used
• One-time values allow detection of replays
• Time is a useful concept for a nonce value, provided the time source can trusted
• attractive
• Nonce values detect replays — they do not prevent them
• Trusted time service is an important common security
• Trusted time service provides reliable time stamps for any applications that need them
• Some applications require trusted time stamps
• Trusted time can be delivered from the security infrastructure
• Security processing impacts performance
• Cryptographic processing poses the greatest problem
• Hardware accelerator modules increase performance
• Avoid heavy dependence on cryptographic processing that impacts time-critical processes
• Disaster recovery must be achieved within business critical deadlines
• Speed of recovery must be traded off against cost

10.8. Assessing the Current State of your Security Architecture

• SABSA®methodology process-flow cross-reference
• Planning for a programme of quick wins
• Security Management

11. Logical Security Architecture

11.1. Business Information Model

• SABSA®Matrix cross-reference
• Information is the logical representation of the real business
• Knowledge, information and data — how they are related
• The properties of information
• Static information has long-term stability
• Dynamic information is unstable and changes
• Information security requires certain services
• Dynamic information requires additional protection services
• The Business Attributes Profile defines the full range of services needed
• Transaction processing has special security needs

11.2. Security Policies

• SABSA®Matrix cross-reference
• Security policy captures the requirements for security – what type and how much?
• Security policy can be related to the security domain concept
• Domain policy is set by the owner but a delegated authority (custodian) may implement policy on behalf of the owner
• A security authority implements security policy
• Security policy is derived from risk-based business requirements
• Policy states what is to be done, not how
• Hierarchical model of policy architecture
• Integrated operational risk management policy
• Top-level operational risk management policy
• Cross-reference toChapter 14andChapter 15

11.3. Security Services

• SABSA®Matrix cross-reference
• Security services are logical descriptions, not physical
• Security service types by defensive strategy
• Security service examples under each defensive strategy
• Security services need to work together
• Integrating key security services
• Uniqueness is critical
• Registration prevents unauthorised participants
• Public key certification prevents unauthorised public keys being used
• Credentials certification prevents unauthorised credentials being used
• Directory service is a complex critical piece of infrastructure
• The directory holds an entry on every object
• Objects of a similar type belong to an object class
• Object classes can be subclasses of other super-classes
• An entry is a set of attributes describing the object
• Syntax rules support search and matching operations
• A distinguished name reflects the structure in the directory tree
• Directory functions provide access and management
• Access is provide through an access protocol
• LDAP functional groups
• A search engine is used to match entries
• Directory services are critical infrastructure needed by all other applications and services
• Authentication and access control are needed to protect the directory
• LDAP supports standard authentication methods
• Access control is an issue for the implementer
• Other security services are needed to protect the integrity and availability of the directory services
• Inter-operability suggests international standards
• Authorisation is multifaceted
• Authentication of a claimant to a verifier
• External reference of authentication
• Defining terms
• Possible parties to a scenario
• No trusted third party
• Third party intermediary
• Key distribution for on-line authentication
• Public key certificates for off-line authentication
• Users are special entities
• Users should be decoupled from the extended authentication exchanges
• User AI may be supplied in many ways
• Device authentication is simply a case of entity authentication
• There are threats to remote communications between entities
• Session authentication protects a communications session from being hijacked
• A mutual authentication exchange is required
• The best session authentication uses cryptographic methods and keys exchanged during the authentication handshake
• Not all vendor claims to provide authentication in their products are necessarily sound
• Proving that a message came from the claimed origin
• Proving that a message remains unchanged
• Origin and contents authentication can be combined
• Message sequencing can also be protected
• Protecting against the replay of previous messages
• A one-time value protects against replays
• Preventing the disclosure of message contents
• Protecting against repudiation of a sent message
• Sometimes seeing activity is enough to draw conclusions about events
• Hiding peaks and troughs in traffic volumes

11.4. Application and System Security Services

• Application security focuses on authorised access control
• Previously discussed under entity security services
• Roles provide a means to simplify access management
• Roles can be used to segregate duties
• First level central access control is also based on role
• Real-time role association depends upon a number of factors
• Theoretical models have been discussed previously
• Three types of access control service
• Providing evidence for later examination
• Protecting against changes in stored data
• Access control is one of the methods
• Preventing disclosure of stored data
• Greatest threat is from viruses and the like
• Hackers can also insert malicious code
• Multiple mechanisms are needed
• You cannot completely eliminate the problem
• Malicious characteristics are ‘undecidable’
• New software must be acquired from trusted sources
• Mechanisms are discussed later
• Software licence control needs similar approaches to integrity protection
• Protecting the integrity of configuration data
• Data backup for system recovery
• Software backup for system recovery
• Time is used as a universally agreed value
• The source of time values must be protected from tampering
• Ease of use is critical for successful security

11.5. Security Management Services

• Security management is both procedural and technical
• A logical architecture for technical security management
• Security management means applying policy throughout the environment
• Policies also need to be managed
• Discussed in more detail in the operational layer
• Uses the same logical architecture
• Uses the same logical architecture
• Uses the same logical architecture
• Reporting status from the distributed agents
• Measuring performance against targets
• Things that can be measured
• Approaches to developing suitable security metrics
• Handling unexpected events reported by agents
• Detecting an attempted intrusion
• Things that might signal an intrusion
• Responding to security incidents
• Steps in an incident response process
• Automated response or manual response?
• Progressive problems?
• Minimal sustainable configurations for fall-back
• Handling user-related security problems
• Recovering after a major incident
• Many mechanisms are involved
• Handling the organisational aspects
• Reporting on the status of security
• Security of the physical sites and buildings
• Ensuring the honesty and integrity of personnel
• Securing against environmental threats

11.6. Entity Schema and Privilege Profiles

• SABSA®Matrix cross-reference
• A schema is a rule-set for what information can be stored
• A schema has many benefits
• Changes to data are checked against schema rules
• Schema components
• Attributes type definition
• Objects belong to one or more object classes
• Object class definition
• Roles are associated with objects through special attributes
• You need to design the schema to fit your needs for role management
• The roles themselves are identified through business analysis
• Some common role types
• Examples of specific roles
• Authorisations stored as data structures
• Storing roles in the directory
• Storing other types of credentials in the directory
• Roles and credentials are also stored as objects that describe what they can do
• Certificates and tickets are cryptographically protected sets of credentials
• Certificates are sometime stored as attributes of an object with which they are associated
• Tickets tend to be transitory in their lifecycle

11.7. Security Domain Definitions and Associations

• SABSA®Matrix cross-reference
• Logical domain specification is a powerful tool
• Be clear about the difference between ‘logical’ and ‘physical’
• An example
• The example organisation has many business units and changes structure over time
• There are numerous business partners who are granted limited access through a partner services domain
• An extranet is used for external connections
• No assumptions are made about the physical implementation of the extranet
• There are home workers and road warriors
• The external services domain provides a buffer zone
• The intranet domain must be externalised through external services
• Road warriors also need the partner services domain
• The production domain is an inner sanctum to protect the business applications
• Public web access through the Internet
• The logical domain map is a critical design step
• Middleware provides services integration
• Middleware has within it a number of common service domains
• This domain model is a different view of the same infrastructure seen in the network domain model
• Your logical domain model should be specific to your business
• Each service domain can be exploded up to a more detailed logical architecture view
• Application sub-domains are roles
• Users are in a people domain, information in an information domain
• The extended application domain includes people and information
• The security service management domain
• A special case of an extended application domain
• Domain interactions depend upon domain policies
• An example of sub-domains and their policies
• Policy interactions in the example

11.8. Security Processing Cycle

• SABSA®Matrix cross-reference
• The security processing cycle activities
• Automated security processes
• Defining the logical flow of each process
• A more formal approach could use finite state machine modelling

11.9. Security Improvements Programme

• SABSA®Methodology process flow cross-reference
• Achieving quick wins
• Keeping senior management satisfied
• Understanding and Deploying LDAP Directory Services
• Computers & Security
• Understanding and Deploying LDAP Directory Services
• may not

12. Physical Security Architecture

12.1. Business Data Model

• SABSA®Matrix cross-reference
• Physical layer focuses on data
• This means files and databases
• File systems offer discretionary access control
• Files have permissions set by their owners
• Files are locked during access to prevent concurrency conflicts
• More details under platform security
• File encryption as a means to protect confidentiality
• Tamper-resistant devices can protect keys from disclosure
• Hierarchical key management can be used
• You need to be careful regarding the real entropy level of a password used to derive a master key
• The entropy of the passphrase must be at least equal to the required entropy of the derived master key
• The passphrase needs a physical secure backup for data recovery purposes
• Practical key-management systems use these various methods
• Cryptographic integrity checksums can be used on files
• The DBMS offers a much richer set of functions
• Concurrency of access is automatically managed
• Database hierarchy
• A database comprises tables
• Tables comprise records
• Records have fields
• The DBMS automatically protects integrity
• DBMS sub-systems
• DBMS mechanisms
• SQL is used for database access
• SQL can be used to implement security mechanisms
• Privilege conflicts are resolved in real time
• Extensive audit logging
• Implementing roles in a DBMS
• Resource limitations
• Mandatory access control as an extension
• Multi-level secure implementations can be clumsy
• Logical unity — physical distribution
• Managing independent failures
• Two-phase commitment
• Physical storage on disks uses RAID for resilience

12.2. Security Rules, Practices and Procedures

• SABSA®Matrix cross-reference
• Rules are the interpretation of policies
• Rules support automated decision making
• ACLs contain rules
• Rules are absolute — no interpretation is needed
• Security practices describe behaviours
• Security procedures give step-by-step instructions
• Procedures are product-specific
• Guidelines provide good advice
• Implementation guidelines provide additional advice in specific circumstances
• Cross-reference toChapter 14

12.3. Security Mechanisms

• SABSA®Matrix cross-reference
• A mechanism implements a service
• Some (but not all) security mechanisms are described in ISO standards
• Mapping mechanisms to services
• Many mechanisms require little additional explanation
• Some mechanisms are described in more detail
• Full details can be found in specific references beyond the scope of this book
• Cryptography supports four fundamental services
• If the service is not a variation of these four, cryptography is not the answer
• Cryptographic strength is most dependent upon key-length
• Whatever the mechanism, key management is an issue
• The encryption process transforms plaintext into ciphertext
• Ciphertext is safely transmitted or stored, then later recovered through decryption
• Asymmetric cryptosystems use different keys for encryption and decryption
• One-way (irreversible) functions have many applications
• Successful key management is the main challenge in any cryptographically secured system
• Cryptographic checksums called seals, MACs and MICs
• Hashing does not require a key, although it can be applied as keyed hashing
• The checksums are regenerated by the recipient and compared with the original received checksums
• Key management is also required
• Public key cryptography
• Public keys must be authentic — hence the digital certificate
• Digital signatures prove integrity and authenticity and support non-repudiation
• Efficiency requires a two-stage process with an intermediate hash value
• The mechanisms for authentication exchanges
• One-way, two-way and three-way exchanges
• One-way authentication based on a security association
• Extending to session authentication
• Preventing the replay attack
• Two-way authentication is an extension of one-way authentication
• Three-way authentication uses random numbers in place of timestamps
• Key management could occupy its own book
• Principles of key management
• The key management life-cycle
• Two basic cryptographic architectures
• In-line architecture for network-level encryption
• Peer-to-peer key management
• On-line architecture for application level cryptographic services
• Sophisticated key management using master key hierarchies
• Application types
• Some broad indications of cryptographic strength
• Algorithm strength is not the only important factor
• Cryptographic design and assessment is a job for an expert
• Some other cryptographic techniques
• Strength depends on the attack capabilities of the opponents
• Quantum computing may threaten public key cryptography as a useful technique
• Quantum cryptography may provide the new key management solution
• Workable systems for quantum cryptography are close at hand
• All security mechanisms have potential vulnerabilities
• Two cases studies provide some insight
• The failure is of the protocol, not the algorithm
• Once again this is a protocol failure

12.4. User and Application Security

• SABSA®Matrix cross-reference
• Security mechanisms to implement application-level security services
• The CAM makes real-time decisions
• DBMS mechanisms can be used for application security
• File security mechanisms can provide application security
• Discussed elsewhere under platform security
• Mechanisms built by application developers
• Proving a user’s identity
• Password management raises a number of important issues to be considered

12.5. Platform and Network Infrastructure Security

• SABSA®Matrix cross-reference
• Infrastructure should resilient and fault-tolerant
• Approaches to network resilience
• Resilient host platforms
• Capacity planning and performance management are closely related to resilience
• Host computers run applications
• A platform is hardware plus operating system
• DAC file security is a standard approach
• Common operating system security issues
• Good practice for a production environment
• Super-user privilege is a politically sensitive area
• Super-user access is not the way to run professional operations
• Lack of security at the physical hardware level has been a major issue since the invention of electronic computers
• Traditional physical security has been through secure physical enclosure of the site, or by using tamper-resistant modules
• These approaches suffer from limitations
• New secure hardware architectures are needed
• Intel has announced its LaGrande Architecture for secure hardware
• Intel’s LaGrande is aimed at beating malicious software attacks
• Design principles for LaGrande
• A new generation of hardware architectures
• Informing the user about a trusted path remains an intractable problem
• Carrying forward the example from the previous chapter
• Physical network topology
• Main features
• Physical directory topology
• Resilient real-time mirrored masters
• Geographical separation
• Traffic management is an issue
• Replica slaves provide the solution here
• Frequency of replication
• Managing consistency and convergence
• Replication and currency of information
• Dual local connections
• Traffic patterns and convergence requirements influence your choice of physical architecture
• Close integration of the directory and the CAM is a feature of physical implementation

12.6. Control Structure Execution

• SABSA®Matrix cross-reference
• Mechanisms for implementing control points in the flow of activities and events
• Nature
• Nature
• The Cuckoo’s Egg
• Internet Firewalls and Network Security
• Understanding and Deploying LDAP Directory Services

13. Component Security Architecture

13.1. Detailed Data Structures

• SABSA®Matrix cross-reference
• Smooth integration requires compatible interfaces
• International and de facto standards help to provide the compatible interfaces
• Syntax rules for exchanged data structures is an important area for standardisation
• ASN. 1 is used to build protocols
• There are built-in type
• Standard types for time values
• Different types of character string
• Structured types
• Example protocol
• Hierarchical type definitions
• Object identifiers for registered universal objects
• Binary encoding rules for ASN.1
• XML is extremely flexible and can be used to create any type of’ document’
• XML is the new generation of what used to be EDI
• XML supports any type of electronic business and thus requires in-built security mechanisms
• XML security standards are already available
• XML has a much greater range of application than ASN.1
• XML is less efficient than ASN. 1, but with bandwidth abundance this is unimportant
• Where efficiency is important, ASN. 1 still has a role
• ASN.1 structures are found embedded in XML documents
• Examples of security-related data structures
• XML offers the possibility of far more sophisticated data structures

13.2. Security Standards

• SABSA®Matrix cross-reference
• Standardisation allows components to be integrated into systems
• There are many different standards from many standards bodies
• ISO is worldwide
• Supporting world business
• ISO has important security standards
• Bringing national and international standards into alignment
• In the area of electrotechnical standards
• Defining ‘electrotechnical’
• Overlap with ISO
• Co-ordinates working groups for Internet standards
• Much activity on security standards
• Organisational hierarchy
• An RFC is an Internet standard
• International harmonisation of security product evaluation
• Brings the North American and European evaluation criteria together
• Addressing a global market place
• The US National standards body
• Relevant standards series
• The UK national standards body
• Business continuity management standard being developed
• Standards for international telecommunications
• Some alignment with ISO and IEC
• Technical engineering standards
• Many adopted by ISO and IEC
• Standards for information systems audit
• Focus on IT governance
• CobiT is an important standard
• Standards for object-oriented architectures
• New security protocol standard
• Promoting web services and XML through standards
• UN sponsorship
• Primary body for XML development
• Developing the full potential of the web though standards
• World economic development
• Security management guidelines
• US government standards
• US DOD standards
• Australian standards
• New Zealand standards
• Security focus
• Japanese industrial standards
• Vendor collaboration on standards
• Feeds into international standards
• Security focus
• European telecommunications standards
• Serving the market needs of its members
• Forum for electronic business
• Diverse membership
• Promoting the use of electronic business
• Industry-wide interest
• Platform and device security
• Replaced the TCPA
• Dedicated to practical research in information security
• Standards are driven by the vendor community
• Some vendors issue their own standards
• Consistent good practice across the enterprise

13.3. Security Products and Tools

• SABSA®Matrix cross-reference
• Common types of security component

13.4. Identities, Functions, Actions and ACLs

• SABSA®Matrix cross-reference
• Modular components of web applications
• Decoupling XML from business logic
• Requirements for implementing web services
• XML schema define the specific vocabulary to be used in a given application
• SOAP is a simple, lightweight messaging framework
• The messages comprise a body and a header
• Routing is handled through a series of SOAP Nodes
• Security service definitions are changing quickly
• Encryption of XML documents
• Digital signatures on XML documents
• Digital signatures on SOAP messages
• Key management for XML applications
• Support for basic services
• A language focused on security management
• Unique identification
• Authentication and authorisation
• Trust assertions address wide issues of trust
• Implementing conceptual trust models
• Deployment of trust services as a special type of web service
• Premium trust services
• Future developments
• New standards
• Supporting security assertions
• Another method of supporting security assertions
• Lightweight approach
• Not fully functional
• Competing approaches
• Expressing security policy to implement access control
• Combining and resolving the interaction of complex rules
• Automated reporting of business and financial information
• Statutory and compliance reporting using XBRL
• Advantages of XBRL
• Benefits of using XML
• Malicious code insertion is the main style of attack
• Security architecture must address these attacks
• XML firewall design principles
• XML firewall security services
• Non-web applications are not covered in this chapter because of lack of space

13.5. Processes, Nodes, Addresses and Protocols

• SABSA®Matrix cross-reference
• Positioning of security protocols in the stack
• Simplicity and ubiquity
• A common transport protocol for everything XML
• Modified HTTP
• Secure encapsulation of HTTP
• HTTP over SSL
• SSL is a vendor standard
• TLS is an Internet RFC
• The benefits are often misunderstood
• Strong encrypted pipe with server-side authentication
• What are the real benefits?
• SSL/TLS is only one component of a holistic security architecture
• IPSec summarised: payload encryption and packet authentication
• Limited traffic flow confidentiality
• Flexible use of algorithms
• Ongoing work
• Often misunderstood in terms of what it can do
• Not an application security mechanism
• IPSec provides network security
• Extension of DNS
• Authenticating DNS lookups
• Flexible security mechanism to support connection-based protocols

13.6. Security Step-Timing and Sequencing

• SABSA®Matrix cross-reference
• Actual timing will depend on component performance
• Focusing on component interaction is the key to gaining the best solution

14. Security Policy Management

14.1. The Meaning of Security Policy

• SABSA®Matrix cross-reference
• Cross-references toChapter 11andChapter 10
• Policy is more than just words
• Security policy means something that is alive and well in the behaviour of the organisation
• Security policy is unique to each enterprise

14.2. Structuring the Content of a Security Policy

• How should a policy be structured?
• The purpose of a policy is to influence behaviour
• Its purpose is not to sit on a shelf
• Ask yourself whom you are trying to influence
• If the question is too difficult, the scope of the policy is probably wrong
• Do not include material that has no relevance influencing the target audience

14.3. Policy Hierarchy and Architecture

• The highest-level policy states senior management intentions
• Detailed policies focus on specific groups of people and activities
• The set of policies needed depends upon your business
• Hierarchical model for policy architecture
• Top-level operational risk management policy
• Information security is part of operational risk management
• CA and RA policies
• Specific policies provide more detail
• The lower layers of the hierarchy contain supporting documents
• Rules, practices and procedures align with the physical layer
• Standards align with the component layer
• Implementation guidelines are sometimes needed
• Example

14.4. Corporate Security Policy

• The highest level of security policy
• Corporate security policy is a topic in ISO 17799
• Points to consider in writing a corporate security policy

14.5. Policy Principles

• Principles that may help you to frame policy statements
• Least privilege is proven to work well in some circumstances
• Where knowledge is more important than information, least privilege is of questionable value
• The role of knowledge engineer may require a special privilege profile
• The US Government has access to a vast amount of information. But it has a weak system for processing and using what it has. The system of “need to know” should be replaced by a system of “need to share”.’
• Information classification is one way to manage security policy
• Information classification is originally a military concept to protect differing levels of secrecy
• Objects are classified, and subjects are security-cleared for access to a level of classification
• Multi-level secure systems handle multiple levels of classification simultaneously
• Classification has also been applied to data integrity
• Complex classification schemes can make business operations difficult
• If classification is also applied to availability the complexity increases
• Many classification schemes outside of the military environment are not clearly focused on meeting a business need
• Classification leads to complex handling procedures for those who create and have access to documents and files
• Classified information tends to drift upwards in the classification stack
• Be clear about the added value and business purpose of a classification scheme
• ISO 17799 mentions classification without a clear business focus
• System classification offers a more practical way to manage security policy
• Granularity is manageable with this approach
• There are many benefits

14.6. CA and RA Security Policies

• CA and RA policies are specific to PKI-based architectures
• CA and RA Policy issues
• PKIX standards describe a CP and CPS
• CP definition
• Level of assurance associated with a certificate
• CPS definition
• The CPS explained
• Part of a legally binding contract
• Online publishing of a CP or CPS
• The CP and CPS are orthogonal
• CPS supports trust, whereas a CP supports interoperability

14.7. Application System Security Policies

• System classification as a means to simplify security policy management
• Efficiency and consistency
• Granularity is traded off against efficiency
• An alternative policy matrix
• Issues to be addressed in application security policy

14.8. Platform Security Policies

• Policies are needed for platforms of all types
• Security policy depends on both the technology and the environment
• Granularity of policy needs to be limited for efficiency
• One security policy per platform type
• Cost/benefit trade-offs
• Strategic principles of platform security policy

14.9. Network Security Policies

• A security policy for each network domain and sub-domain
• Security policies for VPNs and firewalls
• Strategic principles of network security policy

14.10. Other Infrastructure Security Policies

• Security policies for a variety of infrastructure elements

14.11. Security Organisation and Responsibilities

• Managing information security requires an organisational framework
• This framework must begin at board level
• The CEO leads executive responsibility
• You need someone at director level to take the senior management lead
• The director in charge is a part-time role
• The director chosen should be a natural champion of information security
• It is best to segregate this director role from any IT responsibility to provide the business focus
• A management steering group provides the forum for discussion of information security issues
• The steering group must have powers and responsibilities that attract senior members to attend meetings
• The chief information security officer leads the operational development of information security
• Other roles in the management of information security
• There needs to be a liaison group for communication with those with varied and distributed roles for information security management
• The hierarchical committee model for information security management
• Board responsibilities
• Executive team responsibilities
• Steering group responsibilities
• Liaison group responsibilities
• Line management responsibilities

14.12. Security Culture Development

• Everyone needs to understand their responsibilities
• Corporate policy signed off by the CEO sends a strong message
• Everyone must understand and live by the policy
• There needs to be constant attention to raising awareness
• Developing an information security brand is one way to maximise awareness
• The brand is used in every context of information security management
• Line managers must set a good behavioural example
• A ‘no-blame’ culture encourages openness and team-based improvement
• Sometimes malice and negligence need to be disciplined
• Reporting of incidents can help to track progress
• A co-ordinated training programme

14.13. Outsourcing Strategy and Policy Management

• IT services are often outsourced
• Non-IT activities are also outsourced
• Principles for managing the security of outsourced services
• Concepts of ownership and custody are useful in the outsourcing model
• Service owners authorise use of the service
• Data owners authorise use of the data
• The model works for both internal and external service providers
• Managing the interface with the outsourced service provider
• Responsibilities for each party to the arrangement
• Assurance is provided through the internal audit departments

15. Operational Risk Management

15.1. Introduction to Operational Risk Management

• SABSA®Matrix cross-reference
• ‘
• Risk Magazine
• Operational risk seen from different perspectives
• Risk management involves trading off one risk against another
• Cross-reference toChapter 9
• Definition of operational risk

15.2. Regulatory Drivers for Operational Risk Management

• Cleaning up the corporate act
• Drivers for increased regulation
• Recent governance regulations
• Financial reporting transparency
• Government surveillance
• Archiving of all corporate communications
• Representing banking supervision in the G10 countries
• Central banks and national regulators
• Harmonisation of national regulations
• The first Basel Accord addressed credit risk
• Market risk was included under various amendments
• Amendment to the capital accord to incorporate market risks
• The New Basel Accord includes operational risk
• Supervision and public disclosure of risk management practices
• Privacy for banking customers
• Standards for electronic transmission of health care information
• Information security is explicitly included
• EU harmonisation of Basel II implementations
• Standards of governance for listed companies
• Statement in the annual report of a listed company
• Turnbull Report: guidance on the Combined Code
• Problems of transparency for shareholders
• Improving transparency for shareholders
• The FSA Integrated Prudential Sourcebook
• FSA requirements for operational risk management
• The use of electronic documents in the food and drug industries
• Compliance mandated for all pharmaceutical firms
• Creating trust and privacy in electronic documents
• Computer security and sound business practice
• Electronic recordkeeping is not mandated, but where it used, compliance with the regulations is mandated
• Regulation of the civil aviation industry
• Licensing of people, organisations and aircraft
• Licensing implies documentation, much of it in electronic format
• European protection of information held on private individuals
• Defined concepts
• The eight principles
• A major driver for information security

15.3. The Complexity of Operational Risk Management

• The banking industry as a case study through which to explore the complexity of operational risk
• Exclusions may seem to be ducking the issue, but by sticking to the simpler areas the accord stands more chance of implementation
• As new advanced risk-modelling techniques emerge these may lead to more inclusions
• Incomplete data on the ‘tail’ risks may present a problem — because these are the catastrophic risks that one most seeks to mitigate
• Computing value at risk
• Fitting a probability distribution for the frequency of loss events
• one-year
• Fitting a probability distribution for the size of losses
• Using Monte Carlo methods to generate the combined loss distribution
• Designating expected losses
• Designating severe and catastrophic losses
• Basel II capital adequacy requirements
• The need to collect and collate loss data systematcally
• Pushing the limits of computational errors – problems in the tail risk areas
• The problem of silo thinking in enterprise-wide risk management
• Ambiguity in classifying risks — when is an exclusion not excluded?
• Different perspectives for different requirements
• Measuring actual loss events is often of more practical use than attempting to analyse their causes

15.4. Approaches to Risk Assessment

• Lack of consistent complete loss data makes quantitative assessment difficult
• Quantitative operational risk data would allow proper risk-adjusted cost calculations
• Only risk-adjusted cost is a measure of true long-term cost
• The past is not necessarily a good predictor of the future
• Operational risk is a black hole in corporate risk accounting
• The banking industry is concerned about systemic failure caused by operational risk
• Qualitative methods as a pragmatic approach
• Business impact assessment
• Thresholds and bands for impact
• Various levels of granularity
• Quantitative methods for business impact assessment
• Categories of business impact
• The business impact assessment process
• Compound probability of an event
• Issues with statistical methods
• Unreliable data is a major issue for quantitative methods
• Operational knowledge and experience is the key to vulnerability assessment
• Technical vulnerability assessment tools

15.5. Managing Operational Risk

• Doing business requires risk taking
• Risk management balances losses and opportunities
• Risk management means deciding what to do about risks you have identified
• Corporate governance implies sound risk management
• The board must have an enterprise risk management framework
• The ERM framework is all-encompassing
• Enterprise risk management conceptual model
• The external threat environment
• The internal enterprise environment
• The corporate governance process
• The risk management process
• Conceptual architecture of an operational risk management system
• AS/NZS4360 is the only national standard for risk management
• de facto
• ISO standard for risk management terminology
• Risk management standards from professional bodies
• The AS/NZS 4360 process is very similar to the SABSA®approach
• AS/NZS 4360 Step 1: Establish Context
• Stating business objectives and analysing the enterprise
• The steps are bound together by ongoing communication, consutaton, monitoring and review
• The output is fed back as part of the iterative process
• Fundamental similarity between standards
• Risk register as the repository of all enterprise risks
• Example structure for a risk register
• Assigning ownership of risk is critical to successful risk management
• Classify risks according to type
• Keep track of how recently the register has been updated to ensure currency and timeliness
• The risk register is an information repository that requires its own authorisation and access control
• Good risk management delivers many benefits

15.6. Risk Mitigation

• Controls are applied to mitigate risks
• There different types of control
• Control decisions should be supported by a cost/benefit analysis
• Good risk management through the application of controls requires you to seek the middle path

15.7. Risk-Based Security Reviews

• A risk-based security review of an existing system is similar to carrying out a ‘before the fact’ risk assessment
• The risk-based assessment process for existing systems
• Establishing the business requirements for security and control
• Mapping the business processes
• Identify risks in business processes
• Associate the process-embedded risks with the Business Attributes
• Capture types and severity of business impact
• Using the Business Attributes Profile to normalise the measurement of impact
• Assess vulnerabilities
• Cakulate overal1 risk rating
• Ratings indicate pass, fail or management decision needed
• Senior management reporting is through the Business Attributes Profile
• Colour coding re’, amber or green displays the worst case risk category in the Business Attributes Profile
• Colour coding red, amber or green displays the proportional spread of risk categories in the Business Attributes Profile
• Deciding upon risk mitigation
• Map Risk High and Proportional Risk to Business Attributes profile
• Presenting the risk mitigation programme to Senior Management

15.8. Risk Financing

• Risks that remain unmitigated must be financed
• Risk financing is achieved through insurance
• Risk acceptance is necessary to provide a business opportunity
• Different organisations have differing levels of risk appetite or tolerance
• Insurers make a profit because of the statistical spread of loss events
• The insured takes some limited risk through the excess of the insurance policy
• Risk appetite is influenced by the spread of risks experienced by a given organisation
• Insurance is used when the spread of risks is poor and there is high concentration of risk that needs to be financed
• Types of insurance vary according to business need
• Self-insurance is applicable where there is a good spread of risks
• The cost of doing business is the first level if self-insurance
• A premium excess is a type of self-insurance
• Capital allocations are made against the potential for major catastrophic risk events
• Self-owned insurance companies offer captives
• Captives can also be rented
• Finite insurance is based on the time value of money
• There are also a number of exotic insurance products based on the capital markets
• Insurance has some shortcomings
• The definition of property can be a difficulty when insuring information confidentiality
• Indirect or consequential losses are often excluded
• Aggregation of losses over many clients can bring down an insurer
• New threats are difficult to subject to actuarial analysis
• Insurance tends to lag behind the emergence of new risks
• In an increasingly knowledge-based economy conventional insurance may not be enough

15.9. The Risk Management Dashboard

• Dashboards are used by managers to monitor current status of the business
• Risk management dashboards are needed at all levels of management
• The SABSA®Business Attributes Profile can be used directly as a risk reporting dashboard
• Use traffic light colours and click on for drill-down
• The drill-down through hyperlinks provides high usability
• Ongoing monitoring and collection of data allows you to calibrate the effectiveness of controls
• Many organisations apply a baseline control standard
• Multiple dashboard views of the risk profile
• XBRL is an XML-based business reporting language
• Specialised sub-sets of XBRL are emerging as an interface standard for risk reporting

16. Assurance Management

16.1. Assurance of Operational Continuity

• SABSA®Matrix cross-reference
• Operational continuity is related to the SABSA®Business Attributes Profile
• Assurance is provided by inspection of some sort
• Detailed discussions follow

16.2. Organisational Security Audits

• A summary of the audit and review programme
• There are external standards that are used as audit frameworks
• CobiT®is from the IT Governance Institute
• CobiT®addresses the broad issues of ICT governance
• CobiT®is mature and represents international opinion
• The CobiT®document set
• Using the ISO/IEC 17799 ISMS as an audit standard
• ISO/IEC 17799:2000 is a management standard, not a technical standard
• BS 7799 in two parts
• ISO/IEC 17799 will not move to integrate Part 2
• The process for managing the ISMS
• The PDCA model
• BS 7799-2 control objectives and controls
• BS 7799-2 implementation guidance
• Cross references to other management systems
• Internal ISMS auditing
• Qualified auditors for CobiT®and BS 7799
• The CISA qualification
• Alignment of CobiT®and CISA
• Qualified BS 7799 ISMS auditors
• The ISMS audit
• ISMS statement of applicability
• Grades of ISMS auditor
• Criteria for becoming qualified as an ISMS auditor

16.3. System Security Audits

• Security auditing defined
• Three types of auditing activity
• Security audit strategy
• Auditing against accepted standards
• Creating the policies and standards —Chapter 14

16.4. System Assurance Strategy

• Balancing the risks: speed versus assurance
• Risks conflict here, as in many other areas
• Finding the balance: risk management
• Problems in small ICT departments
• Development control strategy
• High-level software development lifecycle
• Code flows from one stage to the next
• It is impossible to test your own programs
• Failed code goes back to the beginning
• Emergency fixes need to be supported with a special process
• Regression testing
• Vendor security patches — emergency fix or not?
• Risks and costs are always being balanced
• Production control strategy
• Multi-tiered strategy
• Malicious code defined
• Control techniques
• Control strategy
• Acceptable use defined
• Unacceptable use examples
• Content management strategy

16.5. Functional Testing

• Functional testing defined
• Black box testing
• White box testing
• Using black box testing
• Regression testing
• Verifying the absence of unwanted functionality is difficult
• Key elements of a testing strategy
• Multi-phased functional testing
• Testing of each individual software module
• Part of the code development process – debugging as you go
• Exhaustive white box testing approach at the unit level
• A testing infrastructure is needed
• Testing the integration of already tested modules
• Integration testing needs to be planned along with the integration itself
• Validating the functionality of the system as a whole
• Ensuring that system validation test development is future-proofed
• Complexity limits the feasibility of exhaustive testing
• System performance validation is an important part of system testing
• Before hand-over to the users, they need to do their own tests
• Planning of the UAT is of critical importance to its success
• Classifying problems identified during UAT
• User sign-off and acceptance
• Before acceptance of a system into the operations environment, the operations group must test that it is operable
• OAT is concerned only with operability, not business functionality
• Operational sign-off and acceptance
• Software QA defined
• Good quality software
• Other aspects of software QA
• CMMI to benchmark development process maturity

16.6. Penetration Testing

• Penetration testing for dynamic systems
• Up-to-date expertise is required
• Levels of penetration testing
• Developing a penetration testing strategy
• Guidelines for the Management of IT Security
• Software Verification and Validation: A Practitioner’s Guide

17. Security Administration and Operations

17.1. Introduction to Security Management and Administration

• SABSA®Matrix cross-reference
• Chapter 11cross-reference
• Prevention brings together many threads
• Routine operational management is also required
• The basic operational and administrative framework is described in ISO/IEC 17799:2000

17.2. Managing the People

• Information security is part
• Personnel management practices can protect against emloying the wrong types of people
• Segregating duties and implementing dual control increases security
• Dual control has many ways of being implemented
• Fraud prevention measures often apply dual control
• Delrgation to deputies protects business continuity
• Independent monitoring or auditing is one solution
• Beware of collusion amongst close friends or relatives
• Keeping a fraud hidden often needs constant attention
• Enforced annual leave is a good way to reveal ongoing frauds

17.3. Managing Physical and Environmental Security

• Physical security is based upon enclosed areas with impenetrable perimeters
• Authorised access through the perimeter requires suitable controlled access points
• Segregation of duties must be applied to guarding activities
• Access is allowed only by authorised personnel
• Equipment and services require protection from malicious tampering
• Procedures are needed for equipment maintenance and removal
• Theft is controlled by ensuring that all valuable items are locked away

17.4. Managing ICT Operations and Support

• All key operating procedures should be documented in detail
• Change control maintains the stability of the operating environment
• Change management differs from change control
• Change management applies to the management of major changes to working practices
• Change management encompasses many issues
• Change management must be integral within information security management
• Many diverse types of incident need to be handled
• Incident impact assessment is the first step
• Incident management is largely an operational process
• The procedures for incident handling
• Potential conflict between incident management and problem management
• Good practice requires separation of system development and systems operations
• Capacity planning has several areas of application
• Capacity planning deals The with future requirements
• Lack of capacity leads to business interruptions
• Acceptance testing requires both UAT and OAT
• Refer toChapter 16
• Ongoing release management
• Strategy for malicious software protection
• Refer toChapters 11and16
• Data backup enables disaster recovery
• Backup strategy
• Backups require testing
• Managing backup media
• Operator logs record operator activity
• Operator log specifications
• Media types
• Media handling procedures
• Ensure that equipment for media support is still available
• Network operations procedures
• Controlling the use of software licences
• Processes for controlling information exchange
• Information exchange mechanisms
• Examples of outsourced ancillary services
• Controlling on-site contractor personnel
• Access management processes
• Processes for managing outsourced ICT operations
• Issues to be addressed
• The asset register
• Configuration management defined
• Benefits of asset management and configuration control
• The service level agreement explained
• Change control over the SLA
• Addressing operational security in the SLA
• Formal agreements are the safety net
• Success depends upon a good relationship
• Goals of relationship management
• Techniques for relationship management
• Training in skills and procedures
• Keeping the business informed
• Types of reporting
• Supporting service development and improvement
• Tailoring the reports to the needs of the recipient
• Logging significant events for audit purposes
• Event types
• Event log formats
• Event log storage
• Event log archiving
• Tools for event log management
• A detailed discussion is beyond the scope of this book
• The forensics process has certain key goals
• Forensic investigation is best carried out by trained and experienced experts
• Problem management seeks to eradicate causes
• There can be conflicts with incident management
• Two main types of problem management
• The problem management process
• Co-ordination of user-related problems
• Help desk support characterises the user perception of service levels
• Specialised technology support is an important part of the help desk infrastructure
• Three-level support
• Help desk support is often focused upon security-related user problems
• Dynamic setting up and configuration of components in complex distributed processing environments
• The provisioning process
• Security provisioning as a sub-set
• Budget management for operational services

17.5. Access Control Management

• Refer toChapters 10and14
• Business requirements drive access policies
• Operational management and administration of user access privileges
• The user access management process
• Use of raw system-level accounts is best avoided
• System-level privileges should be encapsulated to restrict activities under routine circumstances
• Raw system privilege is reserved for emergencies only
• Cultural barriers often obstruct professional considerations
• Refer toChapter 12
• Types of third-party access
• Legitimate third-party access
• Principles of managing third-party access
• Third-party access policy in relation to the policy architecture

17.6. Compliance Management

• Specific information security compliance requirements
• Elements of compliance strategy
• Governments exert control over cryptographic technology
• Cryptographic technology is treated in the same way as weapons technology
• Complying with regulations requires detailed attention
• Important international agreements
• This issue must be proactively managed

17.7. Security-Specific Operations

• Refer toChapters 10and11
• Processes for managing security mechanisms
• Processes for managing security components
• Processes for user management

17.8. Managed Security Services

• Outsourcing the management of certain operational security services
• Outsourcing strategy is discussed inChapter 10
• Benefits of outsourcing managed security services
• Issues to be addressed
• Strategic principles for outsourcing managed security services
• Who is responsible and who is liable?
• Responsibilities and liabilities

17.9. Product Evaluation and Selection

• Procurement of security products needs careful evaluation
• ITTs are often badly written
• A poor ITT makes it difficult for a vendor to make a good bid
• More effort should be invested in getting the ITT right
• First understand what the marketplace has to offer
• If necessary get some help from consultants to write the ITT
• RFIs and RFPs are more flexible than tenders
• Selection criteria must be clear from the outset
• Business Attributes can be used to construct an evaluation plan
• Weighted scoring can be applied
• Also applicable to evaluating outsourced service delivery

17.10. Business Continuity Management

• BCM is an important aspect of operational management
• A process-centric approach is most logical way to tackle business continuity management
• Meta-processes in large enterprises
• Top-down business process analysis
• Achieving up-to-date process models with delegated ownership requires a sophisticated software tool
• The BCM process
• Checklist of BCM activities