Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Security Policy Model Creation for a Networked World

  1. #1

    Security Policy Model Creation for a Networked World

    Devising Information Security Policies


    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.


    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


    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:
    This package;
    Timestampk ;
    Address Information;
    Digital Signature/Message Hash;
    Data: (Contract Document)k

    This could also be expressed in XML like statements


    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.


    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.
    No one can foresee the consequences of being clever.

  2. #2
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Washington D.C. area
    You missed a *major* part of the new era of policies - external mandates. Law makers now have their hands in your pockets when it's time to consider policy/technology/procedure practices. Without including details on how to navigate with this new variable, the tutorial is considered dated and not very useful even with the spiffy section on the "new way" (which is already old) of dealing with the issues.

    This entire tutorial can be summed up in one small formula:

    Business Requirements + Mandated Requirements = Technical/Policy/Procedure Solutions.

    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  3. #3
    I rather think you have missed the point. This is an engineering model which should be capable of expressing mathematically or algorithmatically any external legislative requirement.

    It is not the 'security policy' but the 'security policy model'. Hopefully, the actual policy will be tighter because this guides it.
    No one can foresee the consequences of being clever.

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Washington D.C. area
    Engineering and management models are dynamically opposing forces. I haven't missed a thing but thanks for caring.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  5. #5
    And this is precisely where the problem lies. The threat model should drive the security policy model which in turn should drive the procedural (external legislative and as well as internal managerial) and technical (security target specificiation, product evaluation criteria and component configuration settings) aspects.

    But you are right, we don't live in an ideal world
    No one can foresee the consequences of being clever.

  6. #6
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Washington D.C. area
    The other little nugget that should be mentioned is that no good can come when developing a security policy while the security team (assuming that they are tasked with the job) is positioned under the IT branch in the org chart.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  7. #7
    Senior Member genXer's Avatar
    Join Date
    Jun 2005
    The other little nugget that should be mentioned is that no good can come when developing a security policy while the security team (assuming that they are tasked with the job) is positioned under the IT branch in the org chart.
    We have battled this for years - with some of us suggesting that IT Security should actually be reporting up through Corporate Security, separated from IT.
    \"We\'re the middle children of history.... no purpose or place. We have no Great War, no Great Depression. Our great war is a spiritual war. Our great depression is our lives. We\'ve all been raised by television to believe that one day we\'ll all be millionaires and movie gods and rock stars -- but we won\'t. And we\'re learning slowly that fact. And we\'re very, very pissed off.\" - Tyler (Brad Pitt) Fight Club.

  8. #8
    You are still mixing up a management policy (which is normally a bunch of useless platitudes) with an engineering concept that can be used to verify your security architecture. However I agree about the position of IT security in any organisation
    No one can foresee the consequences of being clever.

  9. #9
    Join Date
    May 2003
    I wanted to like this tutorial, but I had a hard time.

    First of all... you dismiss high level policy as "meaningless soundbites" and the applaud "soundly engineered" principles... I have a question for you. How do you know those principles are soundly engineered? The first step is verification; does this do what it is supposed to? You have dismissed what it is supposed to do as "meaningless soundbites".

    Your incomplete example of the Bell-LaPadula model didn't just arise out of thin air you know. Somewhere along the way a meaningless soundbite came out that looked like this:

    "Data of one classification must not be disclosed at a lower classification."

    You are confusing a system's security policy with an organization's security policy. There is no room in the organization's policy to describe specific access control models used.

    Just as an aside, people messing up access control/state transition models is a big pet peeve of mine:
    The B-L Model is a multi-level model, not a multi-layer model. Access controls represent a single layer of a system's security; this access control however, features different levels of data.
    Next you described the model as: "No process may" this should be "No subject may" the difference may seem subtle, but I assure you it is very real. Subject includes applications and their potential rights as well as anything actively representing users.
    This access must be defined against objects, not simply universally as this would rule out the use of trusted subjects.
    Lastly, though you covered (sorta) the simple security a *-property you neglected to tranquility principle, which is what makes the policy mandatory.

    You have totally confused what a security policy model is as well. The Bell-LaPadula model, your idea of an appropriate organization security policy model does not address any protection goals nor is it agreed upon by the entire community.

    Next you totally change gears and start quoting ISO-15408, which is a system and subsystem security evaluation standard, NOT an organizational security policy. So I am not sure how these are the slightest bit relevant.

    I guess for the rest of this you will be talking about system security so I'll ignore your statements about management, because they just make this even more confusing.

    Sometimes we have to invent new models? The basic models are so vague I don't see this being an issue... but ok.

    You concerns about "pumping" data around is addressed by trusted subjects in the Bell-LaPadula model. Please do you homework a little more carefully next time.

    Your concerns about adapting the military model for need to know is also addresses by the Bell-LaPadula's use of discretionary access controls as well. Again, please read up a little more before your next tutorial.

    Once you get to inter-organizational connections you really go off the deep end. When connecting o remote systems you are dealing with many layers of security.

    Each organization has their own security policy. Below this each organization has it's related regulations, standards, and guidelines. Below this each organization has procedures, which deal not only with the specific manner in which the technology is handled, but what specific technology is used. In side of this you have your network architecture, network security, operating systems and their security, as well as services and their security. Each of these levels and each of the objects using different security models appropriate to their function.

    So connecting to the passport office is a complete connection, governed by the security model of the web server, which is contained by the operating system, and so on. The passport office then connects to the criminal database, and that is a complete connection, they do not connect you to the database... the same is true for pretty much all multi-organizational connections. They connect at a point that has a security policy designed for the specific purpose of connecting to those other organizations. You state transition or access control models have nothing to do with it.

    You again start blending models... are you familiar with the concept of black boxing? Because you really seem to think that everything should somehow be blended into this single monolithic model, which by the way would be WAY too complicated for formal verification for a loooooooooong time.

    Your description of such a model is a waste of my time to even address it.

    Now for your conclusions:

    1. Don't ever write another tutorial again. Without managerial statements, what guides the information security process? Where is the support? Where is the focus? What are you verifying against?

    2. I really mean 1.

    3. ISO-21827

    4. Isn't it better to get them to state the policy, this way if you come to them with something they don't like you don't get fired for having wasted time at work doing something that was unapproved? Also, keep in mind that as an information security employee, it is very likely that you don't fully understand the organization and its needs like say the CFO, COO, CISO, CSO, and CTO might?

    5. Use it to secure your printers, and your LED's from optical eavesdropping, use it to control what your employees talk about at lunch...

    6. Yes and then contact every organization your work with and tell them you're taking over their information security departments... don't worry about asking them before hand, they'll just hand you a bunch of "meaningless soundbites."

    7. Yes, forget securing each point appropriately to its role, we must focus on a single security model to control everything from how we do online banking to how we access milk from our glass.



  10. #10
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Wasn't this written by that guy from Deliverance?.... Ah well. If they ever make a remake of that movie, you SOOOO need to try for the dude that says "SQUEEL BOY SQUEEL!"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts