Re: tunnel vs open a hole

[mag () bunuel tii matav hu (Magosányi Árpád)]

A levelezőm azt hiszi, hogy Dana Nowell a következőeket írta:

[]
> Other issues include:  
> How many CEOs have lost their job due to an Internet break-in?
[]
> How many companies have gone out of business due to a bad security tool
> choice (or any other software bugs)?  

I bet that behind most of the crackdowns of companies in the IT
dependent area you would find bad management of IT development
and operations. But it is mostly unknown, because most people
(even among techies) do not realise that they simply should not
throw out that money in the window.

> How many techies have said, "we need X or the sky will fall" yet the sun
> came up in the morning?

This is also a valid point.

> How many break-in COST stats are publically available and what is their
> confidence level?

> To the average CEO/COO/CTO the cost of security vs. the value is STILL
> black magic.  Some of us have been around the block, some people work in
> the industry, we have a good feel for 'worth', but the average guy doesn't
> necessarily have either event in his favor.  

Here I want to report a major breakthrough:)

Recipe:

0. Get the LSPP and the Cobit control objective list. Do a _thorough_ security
audit using them on some of your key systems. Do not let some third parties
do it, unless you have positively ensured that they have the knowledge to
audit the hell off your systems. If you did not find at least 5 critical,
15 major and 30 minor issues, than you are either don't need my recipe
or you need more training on cobit and cc. If you are clever enough, the
low-level operational staff will love these audits, because they know
a lot of problems, and some of them bothers them enough that they will be
happy to see them as audit findings. Present the audit findings to the
management to make as great a shock as you can. Be prepared to have a
feasible scenario of 0wning the system for all of the critical findings,
and to be able to explain it to suits. Also have proofs of them handy.

1. Review your top-level information security or IT security document. It needs
a review anyway:) Key points (look at Cobit and BS7799-2 for others):
-define data classification rules understandeable for a suit
-define feasible and detailed set of technical requirements and process
        control objectives against each data classification level. (Use
        CC and Cobit.) The rules should be hard enough to have a good sleep
        at night, and loose enough to be doable. Start with an industry level
        protection profile which is harder than your requirements, and
        lighten it. In this way you can always tell 'em how your requirements
        are much easier than the original ones.
-make it mandatory in the top level document that each of your corporate
        data have an owner. This owner is _not_ the CIO, but the C*O who uses
        the data in the system. This owner should classify its data, hence the system,
        and responsible for its security, including system-level security
        policy. He gives the money.
2. have a template for system level security documentation. This should be mandated
        by the top level document, but not necessarily defined there (because
        that is too short to contain 2-5 protection profiles and some hundred
        pages of detailed control objectives). The main idea is that the
        system level documents will document what you want to achieve,
        and the delta between the documentation and real life. Key points:
        -documentation of processes, roles, and responsibilities. Emphasize
        controls of IT support processes. Make it the main part of the document
        as it have concepts understandeable for an average techie, but ensure
        that it still have steep enough learning curve. This is to have those
        people who will write it their first dose of security culture. Keep
        this dose just under the lethal one; they will need this training.
        -Security Target of the system, CC style. Make it an appendix, tell
        them for now that they have to have it from the developer.
        -Deviations. This is the most important part. You do all this hocus
        pocus for this part. The deviations from either the process or
        technical parts should be listed here, each with an action plan
        (or with the statement of the data owner that he takes the risk).
        Make sure that the data owner understands the impact of each deviations.
3. write the system level documentation
        -do not write a single letter of the system level documentation. You know how to write
        it, so no point in doing it. The ones who bought and integrated the system
        into your company should write it. They deserve it anyway:)
        With your, and your ISO900x experts' technical help. It is for educate
        them (including ISO people) about information security, and to have good
        processes. Don't forget to define feasible processes and get them work.
        Base their collaboration on the shock their managers got in step 0. 
        Prepare for long-long workshops, and make them understand the reasons
        behind what you are doing, and its positive effects on the operation
        and quality. Still tell them that they can get the security target
        from the developers.
4. Security Targets
        Well, they sooner or later _will_ get quotes for getting those damned
        security targets. Don't panick. Right now _nobody_ knows besides you,
        what a security target is (or those who do, know that others don't).
        Tell them. Tell it to the managers in an overview level to understand
        the main concepts, and tell to your techies (who got the dose at point
        #3) and your developers in great detail. Tell them at once, to make 
        sure that developers see that your people know more about security 
        than them. Do it when they have realized that they _have_ to write
        the STs. Talk to them about their systems. Emphasize how much you have
        lightened the upstream requirements (since the concepts of CC are
        much extraterrestial to them, they will not realize that in most cases
        you just restated the same requirements in a more understandeable
        form). Frighten them with Bell, LaPadula, Biba, Clark and Wilson,
        the MDIA concept of TNI, or your favourite mania, but only get
        them in the deep for few times for a few minutes. Emphasize that
        the methodologies are for using them with brain. Show them how to
        balance between objectives of the TOE and the objectives of the
        IT and non-IT environment. Having a strong concept of your IT
        security infrastructure and at least some of it working makes
        it lighter for the developers; they will see that adhering to the
        rules means less work for them. Show the connection between
        ST and system level security policy (the security environment
        and OE.*). Show them on an example how to write an ST. Let them
        do it and correct them. Do the training far from workplace,
        allocate one day on concept and two days on technical part
        as a minimum consecutively (We have done it in 0.5 + 1.5 days, 
        but they took 12 hours plus the homework at the end of first day,
        and it seemed a bit shorter than the optimal).
        Now the developers (and their competitors) can make a quote again.

In this way you:
        -enhance the IT security culture of your people and developers
        -have your developers do more quality work
        -have the managers understand the main concepts of security
        -give real responsibility for security to the data owner
        -provide the data for reasonable decisions to the managers
        -have more secure and governable IT

-- 
GNU GPL: csak tiszta forrásból
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards