Security Policy Model Creation for a Networked World
Devising Information Security Policies
Introduction
Is your organisation's information security a bunch of meaningless soundbites or a soundly engineered set of principles by which you devise and check off technical and procedural solutions appropriate to your organisation's business requirements?
What's the difference?
Here is an example of the former -
1. This security policy has been agreed by the CEO and members of the board.
2. The company will keep its data secure using appropriate procedural and technical countermeasures to ensure the confidentiality, integrity and availability of its information in line with its business requirements.
3. Security is regarded as the responsibility of all members of staff.
4. All breaches of security will be reported to Security.
Etc.
Here is an example of the latter –
Bell-LaPadula Model – definition of a multi layered security model based on hierarchical data classification and commonly used by military and government.
1. No process may read data at a higher level (no read up).
2. No process may write data to a lower level (no write down).
The first, although common to many organisations, consists of series of managerial platitudes which are neither specific (e.g. who reports breaches) nor testable in engineering terms.
The latter is a security policy model which is a succinct statement of the protection properties that system (which can incorporate both technical and human aspects) must have. It should be writable in 1 page or less and must contain the protection goals agreed by the entire community. It should also be capable of formal mathematical verification.
Further statements can be broken from this such as -
security target – detailed description of the protection mechanisms provided by a specific implementation used as a basis for testing and evaluation
protection profile – implementation independent expression of the security target to allow for comparable evaluations e.g. for common criteria evaluation
configuration settings – settings specific to a protection product (or the security aspects of a product)
Sometimes we have to invent new models (to deal with new technology or different business requirements). At other times, it is about selecting the appropriate model and making any adaptations to the organisation and hence the security target requirements. Neither route is easy.
Devising a new model
A top down approach would require determine the threat model e.g. in a military system, the ‘insider’ threat (either a software process or a user who writes down from low to high) predominates; in a hospital system, someone who inappropriately writes or reads across information on patients is the greater threat.
Write a policy model which addresses the threat model.
Implement, test and observe the policy in action. Various problems will arise in real world situations which mean that the model has to accommodate added functionality without compromising security. For example, a MLS system might require staff to be able to access a common database at the low end. This means develop a one way ‘pump’ to push data upwards. OTOH data can be formally de-classified and therefore written down. Security mechanisms need to be in place to ensure this is done under authority (i.e. by a responsible principal) and safely (i.e. that a Trojan cannot take advantage of the fact the data is written down to pump its own data stream from high to low)
However, a bottom up approach is also possible where current good practice is observed on a security target and then re-incorporated into its next incarnation (e.g. moving from a physical to an electronic system) and expressed formally at top level as a security policy model. An example of this would be an accounts DBMS which properly incorporates double entry book-keeping (though many don’t and suffer thereby).
Adapting a model
Areas such as the military, banking, and hospitals already have fairly established security models in place. This means that selecting a security policy model is a done deal. However, this does not avoid the need to adapt the model. For example, a top end military organisation may have data classified to TS yet also have further subcategories based on need to know. Clearly, it would be impractical to have further classifications (and clearance processes) but componentisation of data can be achieved through the use of code words e.g. if you have the codeword DESERTSTORM, you can read files related to it but not the file marked BAYOFPIGS, while if you have both code words you can access both. You could also have different code words to distinguish read and write access.
The basic Bell-LaPadula model therefore has to be adapted to incorporate elements of multilateral or role based security as appropriate and re-expressed.
Again, a top down or a bottom up approach is available. A combination of both probably works best.
The Problem of Federalism
In the Internet-worked world, however, we now have an additional problem. Security policy models and associated breakouts such as security target generally assume a readily testable monolithic organisational unit or a community of networks which agree to a common security standard. Unfortunately, as the number of cross connections grow between organisations of all kinds and are necessary for business productivity, this assumption no longer holds true.
The previous approach to networked security between organisations and communities of organisations was to insist on similar levels of security intra-community using Condition of Connection statements. But when John or Jane Doe is connected via their home computer and ISP to the government passport office which in turn connects to a criminal database application, insisting on the same model and level of security across all parts of the connection is clearly untenable. Although the example is extreme, this holds true of all inter-organisational connections.
Need for a New Model?
This suggests that there is a need for new model which can handle security which is neither multi-level, nor multi-lateral, nor role-based but multi-partite in nature and based on flow control. In particular, it should be capable of defining security targets/protection profiles which on the one hand harden boundary mechanisms and network security while at the same time making them more porous and functional (oxymoronic as this may seem).
A possible approach is to define information security requirements in terms of information flows (data nodules) between source data nodes, target data nodes and courier (i.e. interim) data nodes.
The threat model can be expressed –
1. Loss of confidentiality is the result of misrouting (including unauthorised replay) by the source or transport data node.
2. Loss of integrity is the result of interference.
3. Loss of availability is due to the loss of signal or connection.
Possible statements for such a transport based data centric model might include -
1. Security information must form part of the data nodule (e.g. hash, signature, encryption)
2. Source and target data nodes must authenticate credentials on each send and receipt.
3. Local data criticality should be dropped but global data criticality maintained on transfer (e.g. local audit data or local rights would be dropped, but copyright has to be maintained)
4. A goods in process must test for integrity, authentication and non repudiation on receipt.
5. A goods out process should test for confidentiality, authorisation and integrity on send.
6. Courier nodes should transport the data blind, but be capable of detecting/reporting/preventing misrouting, replay, interference and upholding availability.
The difference between this and previous bastion type security approach is that of defending a convoy as opposed to defending a castle.
This can also be verified using simple statements
e.g.
Jonathan (sender), Matthew (receiver), Caroline (attacker), Connie(courier)
For example, Jonathan wants to confirm a contract with Matthew, so he sends him the contract document encrypted under Matthew’s public key plus a reference to the non disclosure agreement under which this document is sent and a digital signature to confirm that he sent the message.
Jonathan >{Connie} >Matthew :: Data_t(Metadata:
(PackageId:
Connection;
This package;
Timestamp;)k ;
Address Information;
Digital Signature/Message Hash;
(SecurityObligations)k;
Data: (Contract Document)k ;)
This could also be expressed in XML like statements
<DataNodule>
<metadata>
<package>PackageId<\package>
<connection>Connection<\connection>
<time>TimeStamp<\time>
<\package>
<address>
<from>Jonathan<\from>
<to>Matthew<\to>
<via>Connie<\via>
<\address>
<signed>DigitalSignature<\signed>
<\metadata>
<data>
CDATA[‘filename.fil’]
<\data>
<\DataNodule>
This upholds the model:
1. Security forms part of the data nodule both in terms of encryption (to ensure confidentiality) and signing (to include authentication) and a time stamped package id to avoid replay.
2. An authentication procedure will take place when setting up the connection and on each send and receive of a data nodule. Since the PackageId is encrypted under a shared key set up at the beginning of the session and valid only for that session this becomes very difficult.
3. The Security obligations probably sent as a reference rather than as a full document reminds the recipient what terms the document is received under i.e. where the recipient is obliged to uphold the sender’s security responsibilities.
4. The goods in process can test integrity, authentication and non repudiation using the digital signature and message hash
5. The goods out process would be to ensure that for example, a history of document changes would be erased before transmission and that the person sending was authorised to release the document (this information would exist in a pre-release form of the data nodule which for example would state who was locally responsible for the document’s security, user access and permitted functionality).
6. Connie, if used, can record the delivery and report any problems. All Connie needs to look at is the address information and the package id information.
Caroline will be faced with any number of points of failure in attempting to attack this connection.
Conclusion
1. Don’t ever write a bunch of management statements as a security policy again.
2. I really mean 1.
3. Select, adapt or devise a security policy model appropriate to your organisational needs which is based on a simultaneous bottom up (good practice) and top down (formally verifiable) approach.
4. Agree the security policy model with management (call it a summary of security aims if you like but get them to agree).
5. Use it verify your network architecture right down to the component level and to assess product choice and configuration and procedural aspects of your security architecture. If you have the power, use it to drive forward product functionality.
6. Start 10 years ago to think about multi-partite and internetwork data flow security issues and what it requires by way of a differentiated security trust model.
7. Forget bastion type security models, their time is done. Models like the above will start to apply both internally and externally.
