White Paper
Security Accreditation:
Not Just a Tick in a Box
Autumn 2013
In this white paper
Security accreditation is too often approached as a ‘box ticking’
exercise. There is an opportunity cost here little acknowledged.
This white paper from Thales UK provides simple, meaningful advice to Project Managers on the security, operational and financial benefits of establishing and maintaining links between security related activities and wider project work streams.
Executive Summary
The potential benefits of security accreditation – in terms of security, operations and finance – too often remain unrealised by those project managers who approach security merely as a ‘box ticking’ exercise.
The prevailing discourse around accreditation is focused on the production of security related deliverables to the satisfaction of a system Accreditor and strict adherence to Information Assurance policy – without a clear understanding of the benefits of establishing and maintaining links between the security related activities and wider project work streams. Consequently security support is only enlisted at a late stage to produce a security deliverable for a design that has not been considered from a security viewpoint. This can lead to eleventh hour attempts to add security measures, which is costly and seldom mitigates the identified risks to an adequate level.
Security Accreditation need not be complicated or expensive. However, like any other engineering activity, it must be based on sound and proportionate requirements combined with the rigorous application of best practice processes.
In this case, best practice is based on a formal security risk management process, which formally captures and, where appropriate, mitigates potential impacts to the system/services or capability.
You may be led to believe that all that you must to do is produce a set of security documents prior to final acceptance. For example, a Risk Management
& Accreditation Document Set incorporating a Technical Risk Assessment, Risk Treatment Plan and some Security Operating Procedures. This approach is liable to result in you being unable to create an assured, secure deliverable and to meet an Accreditor’s needs.
You may also fail to achieve an optimised security solution i.e. a cost-effective security solution that meets all of the functional requirements. The typical
‘workaround’ is to engage in a last minute activity to bolt on security late in the development cycle (or even in the manufacture phase). More often than not the outcome from such an approach is a series of modifications that make the capability secure, but unfit for its intended purpose and an impediment to business processes.
In order to develop a secure system, a clear understanding of the business processes, the associated risk appetite of the business and the effect of the security architecture on the user community are essential. To achieve this, project managers should engage early with appropriately qualified security experts, combined with timely planning and execution of security accreditation and risk management processes. A successful Project Manager will ensure that an assured, secure system is created and the resultant project realises benefits to cost, improved performance and reduced levels of post-delivery support.
A successful
Project Manager
will ensure that
an assured, secure
system is created
and the resultant
project realises
benefits to cost
By applying sound risk management processes, both on specific projects and within the general organisation, a clear link can be achieved between the business objectives and cyber security risks to ensure that investment decisions related to control measures are proportional to the risks and that they are consistently and effectively being managed.
Good Cyber is Good Business.
Introduction
Cyber Security makes headlines on almost a daily basis - the threats and risks posed by espionage are global in scale; these are now widely recognised as often being carried out by state-sponsored, professional, highly focused and extremely adept belligerents.
This is why government, leading cyber security companies and UK businesses must come together to build the awareness, support and capability required to protect UK Plc. The UK Cyber Security Strategy, in place since 2011, sets the four strategic aims of:
Making the UK one of the most secure places in the world to do business in cyberspace
Making the UK more resilient to cyber attack and better able to protect our interests in cyberspace
Helping shape an open, vibrant and stable cyberspace that supports open societies
Building the UK’s cyber security knowledge, skills and capability.
Those involved in the provision of services/capability to UK Government
Departments will expect to be required to meet some level of security. Indeed, the Security Policy Framework1 (SPF) Mandatory Requirement (MR) 8 requires that:
“all ICT systems that handle, store and process protectively marked information or business critical data, or that are interconnected to cross-government networks or services […], must undergo a formal risk assessment to identify and understand relevant technical risks; and must undergo a proportionate accreditation process to ensure that the risks to the confidentiality, integrity and availability of the data, system and/or service are properly managed.”
In Government (HMG) terminology, an Accreditor is responsible for ensuring that accreditation processes comply with relevant HMG standards and procedures, and for agreeing any exceptions with a Senior Information Risk Owner (SIRO) and IT Security Officer (ITSO) on a risk management basis.
1. HMG Security Policy Framework v10.0 Dated Apr 2013
Project managers delivering into HMG will often be presented with a rather ambiguous requirement that reads along the lines of:
‘The system shall be accreditable in accordance with …’
What should a Project Manager, who is new to security accreditation, do to ensure that their project is executed to meet this requirement?
This white paper will help project managers better understand the accreditation process and the wider implications for project management. It articulates in simple terms the relationship between security related activities and wider project disciplines. In doing so, it provides meaningful advice on how project managers can extract maximum benefit in terms of solution optimisation.
Security Accreditation: Getting It Right
For typical, larger-scale procurements, the Vee-Model illustrated in Figure 1 applies, which serves to emphasize the relationship between the procurement body2 and the supplier(s).
Figure 1 clearly shows that security-related requirements need to be assessed prior to contract award; where formal security accreditation is to be undertaken, appropriate contractual requirements need to be specified to ensure that sufficient rigour is mandated through the supply chain.
Figure 1 - Typical procurement Vee-Model
Project Managers must address security to ensure that assured, secure systems are delivered. Failure to plan and execute the appropriate accreditation-related activities will increase the risk (in terms of cost, schedule and performance) of failing to deliver. As the development lifecycle progresses, omissions become more difficult to bridge, if not impossible to rectify. The correct guidance, as reflected within Government (HMG)3 policy, is to integrate security activities from the inception of all projects, engaging with a system Accreditor and appropriately qualified security experts to establish and agree an approach to accreditation, which is proportionate to the service/system being developed.
Prime Supplier
Suppliers Sponsor
Contracting Body User
Requirements System
Acceptance
Contract Acceptance System/Requirements
Contracts
Platform/System Design & Sub-System Requirements
IntegrationVerification
& Testing
IntegrationVerification
& Testing Sub-System Design,
Component Requirements
& Component Design
2. In the case of the MOD, the procurement body is not the end User of the service/system and formal arrangements exist between procurer and Users
3. HMG IA Standard Numbers 1 & 2 Information Risk Management Issue 4.0 Dated April 2012
Various accreditation methodologies support accreditation such as HMG (CESG HMG IAS1&2), ISO27001, Defence (JSP440), and NATO and NIST 800-64.
Which one utilised is dependent on the nature of the business and procuring organisation (for example, the Ministry of Defence, Government or a commercial organisation). All methodologies follow the basic premise that you engage with the system Accreditor, user community and, where required, national technical authorities (such as CESG or NATO).
The accreditation process involves:
Establishing the threats, assets and security risks applicable to the implementation.
Determining the appropriate controls (both technical & non-technical) required to mitigate the security risks within the overall business risk management process.
Integrating the technical and non-technical controls within the overall system/
service design taking into account the other functional and non-functional lines of development.
Providing appropriate evidence that the measures implemented are an appropriate level of assurance through evaluation of products/components, testing and vulnerability assessments.
The above process steps map into the typical Vee-Model diagram as illustrated within Figure 2.
Figure 2 - Typical security-specific Vee-Model Prime Supplier
Suppliers Sponsor
Contracting Body User
Requirements System
Acceptance
Contract Acceptance System/Requirements
Contracts
Platform/System Design & Sub-System Requirements
IntegrationVerification
& Testing
IntegrationVerification
& Testing Sub-System Design,
Component Requirements
& Component Design Establish Accreditation Requirements and Key Security Requirements
Verify that System / Sub-system meets Security Requirements Implement System /
Sub-system to meets Security Requirements Design System /
Sub-system to meets Security Requirements
Undertake Security Risk Assessment and establish System / Sub-system Security Requirements
Accreditation Decision
3 4
1
2 6
5
3. HMG IA Standard Numbers 1 & 2 Information Risk Management Issue 4.0 Dated April 2012
A Risk Management & Accreditation Document Set (RMADS) captures security- related threats, critical assets, vulnerabilities, risks and mitigations; it captures the security landscape and associated engineering decisions. In its entirety, a RMADS enables the Accreditor to make an informed decision on whether the holistic security approach protects the business interests to an appropriate level (based on a clear understanding of residual risk and business risk appetite).
As illustrated in Figure 2, the final security accreditation decision made by the Accreditor cannot normally be granted based on contract completion (e.g. on delivery of a secure system) as approval to operate depends on other factors such as operational resources, physical mitigations (e.g. access controls), training and awareness. It is important for the Project Manager to make it clear that the cyber security ‘tick in the box’ cannot be achieved solely by the supplier.
If the Project Manager fails to plan the activities, does not ensure that activities are executed correctly or does not follow risk management processes, then system/
service designs and associated documentation will be inadequate. Poor cyber planning will not enable the Accreditor to be assured that the appropriate risks have been identified and that these have been adequately mitigated.
There is a plethora of manufacturers/organisations who will claim that by implementing their technology, using their bespoke service, incorporating their security mechanisms, tools or toys that the system will be ‘secure’. The reality is that there is always an element of residual risk and the accreditation process ensures that residual risks are approved by the organisation. In doing so, the organisation must review their information risk appetite/tolerance, while ensuring that business objectives are met and the expectations of risk stakeholders within the business are accommodated.
Security Risk Assessment
At organisational level, the Security Policy Framework (SPF) mandates formal Security Risk Assessments. These must be undertaken annually or whenever there are significant changes to risk components. Appreciation the business’
processes and technologies will provide a basis for establishing who may attack the capability and what vulnerabilities can be exploited. This establishes the risks related to the enterprise and its business processes in the context of the impact due to the compromise of the assets. The benefits of conducting this at the inception of any project are to provide a rationale and traceability as to how the solution, whether it is a system or service, adequately mitigates the identified risks. Cyber security companies can help you with this, through services such as Vulnerability Assessments and Penetration Testing carried out by accredited cyber security practitioners.
A comprehensive Security Risk Assessment will explore who, where and how the capability is going to be operated, so as to gain an appreciation of the user environment and the constraints that may be imposed by that operating environment or business process. Clearly the Project Manager needs to ensure that customer expertise is engaged at timely points throughout the project life cycle to gain an appreciation of how they will utilise the delivered system/service.
The business process may require the sharing of data or provision of support with another organisation or group of people in which there is not the same level of trust as the parent organisation. Appreciating this can ensure that the appropriate risks can be identified and mitigated.
It is vital to ensure that there is a clear understanding of what data is processed by the solution, its importance to the business, and the impact of its compromise in terms of Confidentiality, Integrity and Availability (CIA).
In HMG/MOD circles, business-critical data is identified by a protective marking/security classification, which can be mapped to a set of baseline controls to mitigate the risks. Within industry, however, data may be critical in terms of Intellectual Property (IP), personal data or commercial strategy. Data loss, unauthorised modification or non-availability may effect the organisation in terms of loss of reputation and financially, either in terms of market share or fines imposed by statuary bodies.
Establishing the correct information sensitivity levels requires significant scrutiny, not only by an IA professional, but also by board members to strike the right balance.
A senior (board level) authority should make informed judgements about the potential business impacts as any investment or restriction in business process to mitigate risk will need to be underwritten by the organisation.
Applying too high an impact level to data assets could lead to the application of costly controls that may be disproportionate to the impact of the compromise to the data. Conversely, applying too low an impact level will lead to a lower tier of controls and may open the organisation up to greater risk.
The sensitivity level of data is not within the gift of the Project Manager to determine and as such the project is dependant on the customer’s risk
management processes. Project Managers must make sure they have an agreed position as to the sensitivity level of data to be processed by the system/service before they can effectively undertake any security aspects of the project. Any subsequent unforeseen changes during the project life cycle will have a significant impact on the project, in terms of cost, schedule and performance.
Security Requirements Definition
Having established the applicable risks it is important to agree how they are to be managed. The business has to make a careful judgement with regards to how risk is to be treated and determine what risks it can accept, those that can be transferred and those that need to be mitigated by the implementation of controls, whether these are technical or non-technical.
The risk equation should take into account the business’ risk appetite, which articulates the level of risk that can be tolerated in pursuit of the business
objectives. Any risks deemed to fall above the defined risk appetite level will need the implementation of additional controls or higher levels of assurance to ensure that they are adequately mitigated.
Setting risk appetite is a board level judgement as applying too low a risk appetite will be costly in terms of additional controls/assurance or denying access to certain market, so any judgement also needs to take into account the cost benefits of engaging within a particular sector or using a particular process/
technology. The risk appetite may vary across different departments within a business, dependant on the different business activities, their importance to the organisation and the associated technical risk.
The risk management activities will establish specific security controls, which tend to fall into two general types:
Non-technical. Personnel, physical or procedural measures, provided by the user or a combination of the user and service provider as part of a managed service.
Technical. Encryption devices, anti-virus products, pre-evaluated operating systems, and network devices (e.g. Firewalls/Intrusion Detection Systems).
These security controls and the level of security assurance required from each provide an agreed set of security requirements that must be implemented within the design and the security architecture.
Within the context of the wider system design process it is the Security Risk Assessment and the associated risk treatment plan, which inform the System Requirement Review (SRR) and Preliminary Design Reviews (PDR) activities. These provide the rationale as to what the risks are, what needs to be implemented to mitigate those risks and the level of assurance required. Project Managers need to ensure that the customer’s security stakeholders such as system Accreditors and Senior Information Risk Owners are engaged with these review activities to establish and agree that the right risks have been identified and the strategy to mitigate them is adequate and proportional.
Security Architecture Design
Security requirements are then fed into System, Sub-system design and the appropriate non-functional and functional engineering strands. There is a
temptation to arbitrarily mandate a prescriptive set of policies imposing constraints on the business processes without fully thinking through the consequences.
Logically, the security requirements should be tested against other non-functional engineering activities such as Training, Trials, Human Factors, Safety, Integrated Logistics Support (ILS), roles and responsibilities to ensure that they are supportable and can be sold off via the System or Sub-system acceptance processes.
The nature of the equipment, software and technologies that support the storage, processing and transfer of the data assets, in conjunction with a clear understanding of what data is held where, will enable the organisation to gain value for money for any solution. It may be tempting to pool all data into one system/solution, however this may give rise to the application of disproportionate controls, both technical and non-technical on the vast majority of the infrastructure for an element of data that is only processed and accessed by a small
user community.
In most cases, technical measures will typically require a level of personnel, physical and procedural measures to support the security enforcing functionality that they provide. This could place a requirement on the user community or could, for instance, be delivered as part of a managed service. In either case, there may be a need for further training both for ordinary users of the service/system and for more specialist, privileged users to ensure that any technical/procedural controls are effective.
The provision of technical measures such as Intrusion Detection/Prevention Systems, Anti-Virus, Firewalls and encryption products are only truly effective if supported by appropriate resources that monitor these devices, in conjunction with appropriate processes and procedures to react to any alerts or incidents.
In addition, these mechanisms need to be supported through-life with the provision of up-to-date signatures to detect new and emerging threats and key management as attackers adapt and find new ways of exploiting existing and new technologies.
There is usually a need for agility and the necessity to satisfy the customer. If a user is constrained by a solution, then users will look to actively circumvent any controls to meet the customer’s needs. Therefore, any solution must compliment and enhance the business process. Thus early and continual engagement with the customer’s user community should be actively encouraged to ensure that the end product meets an acceptable level of usability.
A careful Business vs Risk balance needs to be struck particularly when fully countering a risk might adversely affect usability, cost, schedule, safety, or performance. Where such a balance cannot be resolved within the delivery team, or the security risk is too great for the Accreditor to accept, then the decision to accept the risk is escalated to an appropriate authority, using the analysis provided in the Risk Assessment. This process is known as the provision of a Risk Balance Case (RBC) and it requires the Senior Risk Owner (SRO), preferably a board-level member, to make an informed decision. In the case of MOD, the SRO is usually a two-star MOD appointment or government equivalent.
Ultimately, at a Critical Design Review (CDR), it is incumbent on the service/
solution provider to demonstrate to an appropriate level of detail that the security solution will adequately mitigate the identified risks. This is done by identifying the components in the solution that will satisfy the security requirements identified in the SRR and PDR and how assurance will be achieved.
Integration, Verification and Testing
This phase sees the gathering of evidence from various sources to prove that the security architecture has been implemented correctly, with the appropriate level of assurance and user operability. Such evidence proves that the system/
service will mitigate the identified potential risks and, consequently, permit the Accreditor to sign off. Evidence will include the RMADS, but will also encompass, where applicable:
Certificates of compliance of pre-evaluated products.
Evaluation certificates of products certified by an evaluation body.
TEMPEST certification of components and/or platforms.
Results from testing of security functionality at Factory Acceptance Test and trials events.
Penetration Testing and Vulnerability Analysis either by the authority or a 3rd party contractor.
Acceptance of the Security Operating Procedures by the user community in order to operate the capability in a secure manner.
Physical inspection and audit of sites and facilities.
The key point to understand here is that this will define a baseline upon which accreditation is achieved.
As the solution/service goes into operation, continued accreditation will be dependent on the continued through-life management of the solution/service, and how security is considered and addressed through any change management process or system/service upgrades. It is important for the Project Manager to make it clear that through-life activities may not be within the scope of the design and delivery of the system/service and that continued operational support might be incorporated within a separate support provision provided by the customer community or a service provider.
A viable and comprehensive security assurance plan, including audit, compliancy and vulnerability assessment activities needs to be articulated in the organisation’s IA Governance policy to ensure that the security controls that are implemented remain effective and adapt to the emerging threats from a persistent and highly motivated attacker. 3rd party cyber security contractors can provide many of these services.
These assurance activities need to be supported by a change management plan that considers all security related changes and determines the impact from a security viewpoint to ensure that the ongoing security posture remains appropriate for the data processed and the technologies utilised within the solution.
Finally, Project Managers should consider their incident management plans. This captures actions required, an escalation process and decision making points.
These need to be undertaken for a given incident type and any contractual or statuary obligations to report to external bodies. This plan needs to encompass aspects such as breaches in physical or personnel security, or a response to a technical attack, such as malware, or alerts from a security enforcing mechanism, such as Intrusion Detection Systems/Firewalls, including processes required to return the business back to secure operation. It should also consider the requirement to support any internal investigation or an external investigation by a statuary body or police agency.
Conclusion
The Security Accreditation process need not be complicated or expensive, but, like any other engineering activity, it must be based on sound requirements derived from rigorous application of an agreed security risk management process. Security Accreditation and security as a whole should not be seen as a ‘box ticking’ exercise, but complements the overall system/service design or business organisation.
‘Box ticking’ leans to a control centric security approach, which will provide a false sense of security. The solution will not establish a through-life compliancy regime or support business processes. Thus users will look to circumvent the solution controls to get the job done. Careful application of the Accreditation process will embrace compliancy controls as a through life activity, shaping user behaviours in a positive people centric security approach.
The opportunity to implement a positive attitude towards security within your workforce represents the next level of maturity in Cyber Security. By harnessing your peoples’ ability to implement good security practice, you increase the number of personnel who are policing your cyber security policy and will be able to create a culture, environment and ethos where security is seen as a positive enabler.
Cyber security isn’t just about firewalls and passwords. People are crucial too.
Humans, their preference to minimise their own inconvenience, their predictability, apathy and general naivety about the potential impacts of their actions, are often the weakest link in cyber security. For more information on the human side of cyber security, download our ‘The Human Component of Cyber Security’ white paper from our website. This white paper discusses the potential impact of this, and what organisations can do to mitigate the related risks.
In order to develop a secure system, a clear understanding of the business processes, the associated risk appetite of the business and the effect of the security architecture on the user community are essential. Early engagement with appropriately qualified security experts combined with the timely planning and execution of security accreditation and risk management processes are essential.
Cyber security isn’t just about firewalls and passwords.
People are
crucial too.
By applying sound risk management processes, both on specific projects and within the general organisation, a clear link can be achieved between the business and cyber security risks to ensure that investment decisions related to control measures are proportional to the risks and that they are consistently and effectively being managed.
We have seen how a smart approach aligning security accreditation and associated activities with traditional project lifecycles adds value to the development process and contribute to an assured, coherent capability at the project level. Not only this, but at a board room level, it can help business leaders make more informed, effective investment decision, and reap the consequent operational and financial benefits.
Good Cyber is Good Business.
A call to action
Our experience has shown us that doing nothing is not an option. Cyber security companies are here to help you equip your organisation to meet the cyber threat at a cost and rigour appropriate to your organisation.
The constantly evolving threat environment is such that you can soon
fall behind the curve and are no longer secure. Cyber security is not a product;
it is a journey.
Thales suggests you begin by understanding your vulnerabilities.
Start by contacting an accredited cyber security provider to review your options.
in 56 locally based country operations make Thales a key player in assuring the security of citizens, infrastructure and nations in all the markets we serve – aerospace, space, ground transportation, security and defence.
Thales is a leading supplier of security technologies to secure your people, places and information. For more than 40 years, Thales has delivered state of the art physical and cyber security solutions to commercial, critical national infrastructure, government and military customers.
In all, Thales delivers cyber security projects across 50 countries, with a global network of 1,500 information security specialists working with SME and research partners that provides it with deep expertise and the agility to deliver industry- leading solutions across the complete cyber spectrum.
Thales believes that Good Cyber is Good Business. Thales will help you refocus your security spend to defend your organisation and prevent significant loss of revenue and reputation. Thales will ensure your competitive advantage is maintained by being able to demonstrate resilient and secure use of cyberspace.
Why Thales?
Thales is a world leader in providing modular, integrated cyber security solutions to protect your people, places and information:
Cyber incident response
Audit, assessment and compliance
Virtual enterprise and network simulation and testing System integration and assurance
Training and skills
We are here to help - a Cyber Security partner you can trust:
Global network of 1,500 information security specialists, building upon 40 years of experience
Extensive domain knowledge of enterprise, defence, transport and energy sectors
Trusted to secure 19 of the 20 largest banks and 80% of payment transactions worldwide
Contact Us
Thales UK Ltd, Mountbatten House, Basing View, Basingstoke RG21 4HJ, UK Tel: +44 (0) 1256 376633 Email: cyber@uk.thalesgroup.com
Website: www.thalescyberassurance.com
© 2013 THALES UK LTD. This document and any data included are the property of Thales UK Ltd. No part of this document may be copied, reproduced, transmitted or utilised in any form or by any means without the prior written permission of Thales UK Limited having first been obtained. Thales has a policy of continuous development and improvement. Consequentially the equipment may vary from the description and specification in this document. This document may not be considered as a contract specification. Graphics do not indicate use or endorsement of the featured equipment or services.
