The InfoSec Blog

Toronto - OWASP

This month’s meeting was about layer 7 errors in web applications. Trey Ford was a fast spoken Texan and gave some good examples.

The common thread, as I saw it, was that no amount of pen testing, no amount of risk analysis would have uncovered these flaws. What they had in common was ‘failure mode’. Its another FMEA situation. The designers were optimists and never conceived of the abuse and trickery that might be perpetrated.

Let me give another Layer 7 example.

One of the lists I belong to forbids Out-of-the-Office messages. If anyone is so foolish as to have one set up to respond to list messages he gets ridiculed on the list. If his message leaves other contact information, we’ll contact those people and tell them of the mistake.

Other lists I’m on seem to suffer from what amounts to OotO broadcast storms. When I submit a post to them I get a flood of OotO messages that compares to my daily spam. Sending OotO response to a mailing list message is dumb in the first place, but its also a security issue. Some of these lists don’t have restricted membership, so someone could join with the express intention of harvesting addresses or other inside information.

Even worse, try googling for “out of the office“. Its amazing how easy social engineering can be.

Your company may mandate the use of OotO, but its most useful internally and should not be used in response to mailing lists. If you are going to use this mechanism make sure you have it set up properly.

Back in 2003, my German friend and fellow CISSP, Axel Eble, wrote a draft RFC about OotO best practices. Sadly it died without becoming an IETF baseline.

See also:
‘Out of office’ messages turned into spam relays

While this point arose from a discussion on the ISO-27001 mailing list, in other InfoSec/Audit forums I’m known as a strong proponent of Failure Mode Effect Analysis (FMEA), to the point where people naturally associated it with me. However it clear in my 20+ years in InfoSec in a number of countries (including the UK, where ‘7799 and 2700x come from) that the accepted FMEA approach is not a normal method of ‘risk assessment‘ and is not taught (or examined for) as part of InfoSec, for example as part of the CISSP.
I learnt FMEA (and other techniques we now bundle under 6-sigma, ITIL and so forth, before they were categorized and labelled) in engineering - physical, electrical and aviation. In general, I’d say that InfoSec has a lot to learn from other engineering professions about managing threats, vulnerabilities and failures, and what actually constitutes “risk”. For a start, we have too much of a techie-geek outlook and we are not well educated in statistical methods.
Just giving numbers is meaningless. I will not trust any ‘graph’ that does not have ‘error bars’ and which does not document the sample size vs the total population and show the variance, for example against a random population. These test are easy to perform and I’m disappointed that so many numerically justified ‘risk analysis’ models are really just a pile of spread-sheet mumbo jumbo with no discipline of process behind them.

Estimating “on a scale of 1-5″ the components of the risk equation for many factors then multiplying out and averaging is pretty meaningless, yet I’ve seen it done by consultants from TLA companies and accepted by managers. At the very least it ignores cross interactions, and is essentially just a “your guess is a good as mine” approach.
I have nothing against opinions about risks, what I do object to is trying to make opinions into solid numbers. That “estimate on a scale of 1-5″ will have an error bar of size >= 5 !

Lets face it, most people don’t understand statistics. All to often I’ve seen managers ignore the “once in 100 years” MTBF (and ignore any MTTR - see FMEA) because they only plan to be with the company for five years, or ignore it because it happened 25 years ago so they think they have a 75 year breathing space. Yes, I know it sounds apocryphal, but I’ve met it too often.

To my mind FMEA is not only easier than TRA, but it focuses the mind on two key issues - survival and recovery (see MTTR) - that TRA doesn’t.

We know that anti-spam (and for some, AV) is a necessary baseline.
(I’ll avoid using the ‘diligence’ words for now.)

But here is a spreadsheet that ‘does the numbers’.

As I’ve said before, the ROI issue isn’t about justifying the project - the normal B-school way of looking at at things. Its about ‘choosing between’. That’s what this spread sheet purports to be doing. The reality is subtly different.
In doing so, it illustrates all that can go wrong with this approach. Basically you are ‘buying in‘ to someone else’s way of looking at the analysis. This is essentially the trick that sales-droids use. They get you to accept their world view, and once you do accepting that their product is the ‘right one‘ naturally follows.

In a way, this is like the conclusion to the Sapir-Whorf hypothesis about linguistic determinism.
“Put simply, the hypothesis argues that the nature of a particular language influences the habitual thought of its speakers. Different patterns of language yield different patterns of thought.”

That wikipedia article also has some references to the use of language as determinism in fiction that are vary pertinent.

Elsewhere I find: “A well-known saying by Alan Perlis states that ‘a language that doesn’t affect the way you think about programming is not worth knowing‘. he’s talking about computer languages, but it applies to natural languages - and of course tools - software tools like spreadsheets, word processors, UML modelers, and things like Photoshop.
So how is this relevant?

There in the spreadsheet are the four categories:

• Difficulty
• Investment
• Capability
• Expandability

No-one says quite what they mean.
The Initial/Daily/Ongoing might appear to clarify, but when you work through it can also add to the confusion.

Is the investment in time or money? Well, if time is money, how are we calculating the equivalence?
Right, another sheet, grade of techie vs bill-out rate.
Well what about things like cost per server, cost per seat? cost per bandwidth?

…. and so on …

How is ‘daily’ different from ‘ongoing’?

…. and so on …

Are these the only categories? Would you break things down more specifically? Would you use other or more categories?
Then there’s the weighting values. Do you agree with them? Are you going to accept other people guiding the judgment, making it appear that you are making the decisions, when in reality they have made all the important structural decisions?
The answer from the numbers-people (you know who you are!) is that it is easy enough to add another sheet, insert anotter row or column, alter the weightings … And indeed it is. For them. They think in those terms - they cannot do otherwise. “When the only tool you have is a hammer you view every problem as a nail“.
But implicit in this is that you accept that culture and its conclusions - that the number (and spreadsheet) are “God”.

In the closing of the First World War, Kipling wrote a poem that poked fun at the established “old wise saying” that many people used to justify action while avoiding really thinking about matters. I see the obsessive use of tools like spreadsheets and the numbers they give - hidden by the arbitrary assumptions of the model - as a similar phenomena.
So lets look at another way.
How would you choose your AV product?

• “Market Dominance“
  As in ‘you never get fired for buying IBM’ updated to the modern world.
  Certainly when the Big Name auditors come along to do your compliance audit they will check “AV” off on their list.
• “Magazine Reviews“
  There are two approaches here. You can ‘blindly’ accept the ‘Editors Choice‘, which is really no different from accepting how they formulated their spreadsheet, assigned weightings and values. Alternatively you can read lots of reviews and form your own impression.
• “Advice of Peers“
  As in ‘this worked for me‘ or ‘I had lots of problems with that one‘.
  In some ways this is like reading lots of reviews, but with a more personal and ‘real world’ feel to it. You can also seek out someone who has a set-up similar to yours so that the context of the advice is more meaningful.
• “Corporate Standard“
  Maybe you don’t have a choice. (I recall a site where ‘policy’ said that all IBM computers had to be in the raised-floor room. It was probably originally justified by insurance, UPS, HVAC issues. However when I audited the site I found a stack of IBM laptops there that had never been used.) Maybe the security is out-sourced or somehow ‘managed’ and details are outside your control. Perhaps there is a “Master Purchasing Agreement” with a specific vendor and if that vendor has a product that is pertinent you get stuck with it.

So how do you make the decisions - not the “decision to” but the “decision which”?

Some of us security types were discussion policy, login notices and the like.

Someone commetned on a badly written poicy about the use of corporate e-mail and discussion about the company.

… I recently worked at a place that had an weak and over specific email policy.
One day management realizes there are other areas where “contraband communication” can take place - internet groups, blogs, forums, IM, Blackberries, etc. If the policy hadn’t been wrtten to deal specifically with “email” or been more general about the level of technology it would have saved us some hassle.
As it was, our policy development and approval process was too sllw and ciumbersome.

This is a generic issue and not limited to e-mail, IM, etc.

Long ago in a policy development workshop that I was running we thrashed out how to express ACCESS CONTROL so that it was perfectly generic, applied to
everything from the parking lot to the executive washroom, was in language everyone from the Board of Directors to the Janitor could understand. Of
course it applied to computer/network access, and its wording marched the requirement of the ‘restricted access’ logon notices.

I’ve been told the lawyers didn’t like it but the reasons seemed to boil down to the fact that the language was so straight forward and unambiguous that there wouldn’t be enough billable hours if it came to a court case.

If you structure your policy management properly so there is a succinct POLICY STATEMENT and ancillary sections that address

• Justification
• Consequences of Non compliance
• Roles and Responsibilities
• Who/When/Where/Why Does this Apply?
• Guidelines for Interpretation
• Relevant Standards (Internal and External)

and of course

• Procedures

then its a very effective and efficient way to work.
This is because

a) You don’t need a lot policies if they are “general”
b) It makes them easy to learn and remember
c) You don’t have to keep going back to the board to get picayune changes approved

Yes, it off-loads a lot of the work to the “Guidelines” and the “Procedures”, but those are going to be very situation specific anyway. If you can get the top level policies done its easy to delegate the details.
And with a web based system, hyperlinks and search engine the “how does this apply to me” and “what applies to me” is straight forward so long as you have a clear idea of roles.

If you don’t, well, there are probably more fundamental questions to askabout your organization such as ‘what the heck is everyone doing?”

A colleague who had the opportunity to restructure the role of his InfoSec department asked for advice about defining the roles and duties and how to make his department more effective.

Being very conservative in some ways I recommended a traditional Separation of Duties. It begins with what might be described, for lack of a better term as “the separation of InfoSec and IT”.

In the limiting case:

in other words InfoSec addresses the areas you’ve expressed concerns about responsibility for by setting policy, standards and requirements (?compliance?). IT is responsible for the implementation, the hardware, the software, its installation and maintenance.

It can be an easy sell if you approach it properly.

Smile when you say that, but don’t make it a predatory smile.

Yes, that makes it sound easy, but reality never is, is it?
That’s why people buy books that offer the same kind of advice.
If you really want to work it through, try the books by The Harvard Negotiation Project:

* Getting to Yes: Negotiating Agreement Without Giving In
* Difficult Conversations: How to Discuss what Matters Most
* Getting Past No: Negotiating Your Way from Confrontation to Cooperation
* Getting Ready to Negotiate

Consultants, that is people with no formal authority in the hierarchy, may also appreciate

* Getting It Done: How to Lead When You’re Not in Charge

(Another time I’ll discuss the stupid idea that HR/HH has of ‘consultants’
having no management skills or experience.)

The technical staff in the IT department may be perturbed in a number of ways. They might feel that their ‘freedoms’ are being removed and they are being ‘policed’. Make it clear to them that YOU are not policing them. AUDIT is policing them. That is the correct corporate role for audit.

InfoSec is writing the specs - the policy, the requirements, and they are doing it in cooperation with not only IT but also with other stakeholders.

This is no different from a software or hardware development situation, or, for that mater, the original set-up and procurement that went onto IT.
Someone did a needs analysis (even if it was only guesswork and a paper napkin), wrote up a requirement and handed it over to the people that “made it so”.

I appreciate that this ‘formal’ approach is being depreciated by ‘agile’ methodologies where the techies work without any of the formal management structure, without specifications or formal requirement, writing and running their own tests, all in the name of “Web 2.0″.

However the original idea as to set up a formal system of division of responsibility and duties and to deal with strengths and specializations.

Many people think that by fitting in with the power of a formal system they are giving up ‘freedom’. They don’t see the power of having all that organization (and buying power) behind them, of having defined roles that offload from them the detailed housekeeping that slows them down. They only think in terms of the Marxist cant about oppressive ‘production lines’ that dumb down the worker into an automation.

This is short-sighted and they know it if they’d stop and think about it.
Lets look at an example out of IT: The compiler - a tool that takes a high level requirement and specification and converts it to the fiddly assembly code - is one they accept. But some of us are old enough to remember the arguments against compilers, that they couldn’t produce the same quality code as good assembly programmer.

Perhaps: that may have been true back 30 years but its not now. Now compilers are ‘expert systems’ in code generation for very complex CPUs and instruction streams and branches. Programmers recognise this and accept it, often without thinking very deeply about it - they just code in the HLL and the compiler “makes it so” that it runs on the machine. But even 30 years ago compilers could produce assembly code to match a ‘good’ assembly programmer
- but at 10 to 100 times the speed and when used by a middling programmer who understood the subject matter of the application better than he did the hardware of the computer did a very good job of delivering the application program.

This is a classic example of abstracting and encapsulating specialized knowledge and division of labour.

I have no doubt that today’s programmers would be upset if you took away their compilers.

What I am suggesting in this separation of duties between InfoSec, IT and Audit is no different from a doctor writing a prescription and the patient taking it to an apothecary to be filled. The apothecary isn’t doing the diagnosis or needs analysis, but he still plays an essential role.

The “You” in InfoSec, have to understand business needs, regulations, compliance issues. The “Them” in IT have to understand the details of the technology they are working with. Each have their roles to play.

Its when people start interfering with these responsibilities that things get upset.

US-CCU has just finished the final release version of their cyber-security check list. A bookmarked pdf copy of it is temporarily available for download from http://www.cyberunitss.com/files/cybersecuritychecklist2007.pdf.

Here’s the press release:

Read the rest of this entry »