The fatal flaw in IT Risk management
Is interviewing is a much better method that self-certifications and a checklist, if time and resources allow.
Two points:
In the ISO-27001 forum, my friend and colleague Gary Hinson has repeatedly pointed out, and I fully support him in this, that downloading check-lists from the 'Net and adopting question lists from there is using a solution to someone else's
problem. If that.
Each business has both generic problems (governments, sunspots, meteor strikes, floods & other apocalyptic threats and Acts of God) and ones specific to it way of working and configuration. Acts of God are best covered by prayer and insurance.
Gary recommends "open ended questions" during the interview rather than ones that require a yes/no answer. That's good, but I see problems with that. I prefer to ask "Tell me about your job" rather than "Tell me how your job ... can be made more efficient".
My second point is that risk management will *ALWAYS* fail if the risk analysis is inadequate. How much of the RA should be done by interviewing people like the sysadmins I don't know, but I have my doubts. I look to the Challenger Disaster. I started in the aviation business and we refines FMEA - failure Mode Effect Analysis. Some people think of this in terms of "impact", but really its more than that, its also causal analysis. As Les Bell, a friend who is also a pilot and interested in aviation matters has pointed out to me, "Root Cause Analysis" no longer is adequate, failure comes about because of a number of circumstances, and it may not even be a single failure - the 'tree' fans both ways!
Yes, FMEA can't be dome blindly, but failure modes that pertain to the business - which is what really counts -- and the fan-in/out trees can be worked out even without the technical details. Rating the "risk": is what requires the drill-down.
Which gets back to Donn Parker's point in a number of his books, though he never states it this way. The FMEA tree can be heavily pruned using diligence as he says: standards, compliance, contracts, audits, good practices, available products. The only thing he leaves out are Policy and Training. Policy gives direction and is essential to any purpose, the choice of standards and products, and identifying what training is needed.
All in all, the article at https://blog.anitian.com/flawed-it-risk-management/ takes a lot of words to say a few simple concepts.
Confusion over Physical Assets, Information Assets in ISO-27000
I often explain that Information Security focuses on Information Assets.
Some day, on the corporate balance sheet, there will be an entry
which reads, "Information"; for in most cases the information is
more valuable than the hardware which processes it.
-- Adm. Grace Murray Hopper, USN Ret.
Some people see this as a binary absolute - they think that there's no need to asses the risks to the physical assets or that somehow this is automatically considered when assessing the risk to information.
The thing is there are differing types of information and differing types of containers for them.
Does ISO 27001 compliance need a data leakage prevention policy?
On one of the ISO-27000 lists I subscribe to I commented that one should have a policy to determine the need for and the criteria for choosing a Data Loss Prevention mechanism.
I get criticised occasionally for long and detailed posts that some readers complain treat them like beginners, but sadly if I don't I get comments such as this in reply
Anton
Data Loss is something you prevent; you enforce controls to prevent data
leakage, DLP can be a programme, but , I find very difficult to support
with a policy.
Does one have visions of chasing escaping data over the net with a three-ring binder labelled "Policy"?
Let me try again.
Policy comes first.
Without policy giving direction, purpose and justification, supplying the basis for measurement, quality and applicability (never mind issues such as configuration) then you are working on an ad-hoc basis.
Control objectives – Why they are important
http://blog.iso27001standard.com/2012/04/10/iso-27001-control-objectives-why-are-they-important/
Let us leave aside the poor blog layout, Dejan's picture 'above the fold' taking up to much screen real estate. In actuality he's not that ego-driven.
What's important in this article is the issue of making OBJECTIVES clear and and communicating (i.e. putting them in your Statement of Objective, what ISO27K calls the SoA) and keeping them up to date.
Dejan Kosutic uses ISO27K to make the point that there are high level objectives, what might be called strategy[1], and the low level objectives[2]. Call that the tactical or the operational level. Differentiating between the two is important. They should not be confused. The high level, the POLICY OBJECTIVES should be the driver.
Yes there may be a lot of fiddly-bits of technology and the need for the geeks to operate it at the lower level. And if you don't get the lower level right to an adequate degree, you are not meeting the higher objectives.
Social Engineering and sufficency of awareness training
Someone asked:
If you have a good information security awareness amongst
the employees then it should not a problem what kind of attempts
are made by the social engineers and to glean information from
your employees.
Yes but as RSA demonstrated, it is a moving target.
You need to have it as a continuous process, educate new hires and educate on new techniques and variations that may be employed by the 'social engineers'. Fight psychology with psychology!
Upside and downside: How I hate Journalists
And this doesn't actually stop them form making use of 'insider information' they just have to declare it within 30 days.
No, wait, sorry ... you mean that the legislators are saying that legislators shouldn't do something that is illegal anyway? Or that, if they do something that is already illegal, it is OK as long as they declare it within 30 days? ...
It gets worse:
I'd like to claim the system is rigged so 'the rich get richer' but if I did that some people who claim they are right wing would accuse me of being left wing. Indeed, this tells me that their political outlook has not progressed since 20 June 1789. This one-dimensional view fails to describe the rich variety of political attitudes in the Washington, never mind the rest of the USA and points elsewhere on the physical compass.
http://en.wikipedia.org/wiki/Pournelle_chart
http://en.wikipedia.org/wiki/Nolan_Chart
Just those two show we need more that 4 axes to describe a political stance. But as I mentioned in a previous post, journalists are simple-minded and expect the rest of the world to be as limited in outlook and understanding.
http://en.wikipedia.org/wiki/Political_spectrum
Try this test:
http://www.politicalcompass.org/
How does this all relate to InfoSec, you ask.
Well part of that Political Compass is a view of 'how authoritarian'.
And that gets back to issues we have to deal with such as Policy and Enforcement, Do We Let Employees have Access to the Internet, and the like.
Hans Eysenk pointed out that the right wing (e.g. Fascism and Nazism) had a lot in common with the left wing (communism). Both are repressive, undemocratic and anti-Semitic. So on these issues, at least, the left-right distinction is meaningless.
How many more such simplistic distinctions such as those foisted on us by journalists are equally meaningless.
Some while ago my Australian fellow ex-pat Les Bell, who apart from being a CISSP is also a pilot, pointed out to me that the method of 'root cause analysis' is no longer used in analysing plane crashes. The reality is that "its not just one thing", its many factors. We all know that applies in most areas of life.
I suspect most people know that too; its not restricted to the digerati.
There is the old ditty that explains how because of a nail an empire was lost, but no-one is proposing that we fix the failing of the "American Empire" by manufacturing more nails.
Except possibly Journalists.
Related articles
- Is your political compass OK post the election? (greenwichlib.wordpress.com)
- Political Compass: May (spinelessliberal.wordpress.com)
- The downsides of experience (cdevroe.com)
- The US Election - 2012 (www.politicalcompass.org)
The real reasons for documentation – and how much
he documentation required and/or needed by ISO-2700x is a perenial source of dispute in the various forums I subscribe to.
Of course management has to define matters such as scope and applicability and the policies, but how much of the detail of getting there needs to be recorded? How much of the justification for the decisions?
Yes, you could have reviews and summaries of all meetings and email exchanges ..
But that is not and has nothing to do with the standard or its requirements.
The standard does NOT require a management review meeting.
TV kills!
I keep telling everybody that TV is injurious to your (mental) health, but does anyone listen?
Why should they?
They didn't when Gerry Mander presented his Four Arguments for the Elimination of Television, and he was in a position to know.
Are *YOU* ready to give up yet?
Apparently (ISC)2 did this survey ... which means they asked the likes of us ....
Faced with an attack surface that seems to be growing at an overwhelming rate, many security professionals are beginning to wonder whether their jobs are too much for them, according to a study published last week.
Right. If you view this from a technical, bottom-up POV, then yes.
Conducted by Frost & Sullivan, the 2011 (ISC)2 Global Information Security Workforce Study (GISWS) says new threats stemming from mobile devices, the cloud, social networking, and insecure applications have led to "information security professionals being stretched thin, and like a series of small leaks in a dam, the current overworked workforce may be showing signs of strain."
Patching madness, all the hands-on ... Yes I can see that even the octopoid whiz-kids are going to feel like the proverbial one-armed paper-hanger.
Which tells me they are doing it wrong!
Two decades ago a significant part of my job was installing and configuring firewalls and putting in AV. But the only firewall I've touched in the last decade is the one under my desk at home, and that was when I was installing a new desk. Being a Linux user here I don't bother with AV.
"Hands on"? Well yes, I installed a new server on my LAN yesterday.
No, I think I'll scrub it, I don't like Ubuntu after all. I'm putting
in Asterix. That means re-doing my VLAN and the firewall rules.
So yes, I do "hands on". Sometimes.
At client sites I do proper security work. Configuring firewalls, installing Windows patches, that's no longer "security work". The IT department does that. Its evolved[1] into the job of the network admin and the Windows/host admin. They do the hands-on. We work with the policy and translate that into what has to be done.
Application vulnerabilities ranked as the No. 1 threat to organizations among 72 percent of respondents, while only 20 percent said they are involved in secure software development.
Which illustrates my point.
I can code; many of us came to security via paths that involved being coders, system and network admins. I was a good coder, but as a coder I had little "leverage" to "Get Things Done Right". If I was "involved" in secure software development I would not have as much leverage as I might have if I took a 'hands off' roles and worked with management to set up and environment for producing secure software by the use of training and orientation, policy, tools, testing and so forth. BTDT.
There simply are not enough of us - and never will be - to make security work "bottom up" the way the US government seems to be trying We can only succeed "top down", by convincing the board and management that it matters, by building a "culture of security".
One view of Enterprise Information Security Architecure (EISA) Framework.
This is not news. I'm not saying anything new or revolutionary, no matter how many "geeks" I may upset by saying that Policy and Culture and Management matter "more". But if you are one of those people who are overworked, think about this:
Wouldn't your job be easier if the upper echelons of your organizations, the managers, VPs and Directors, were committed to InfoSec, took it seriously, allocated budget and resources, and worked strategically instead of only waking up in response to some incident, and even then just "patching over" instead of doing things properly?
Information Security should be Business Driven, not Technology Driven.
[1] Or devolved, depending on how you look at it.
Related articles
- Information Security By the Numbers (michaelpeters.org)
- Malware in Medical Equipment Poses Serious Threat to Hospital Security (eweek.com)
- Re: CISO Challenges: The Build vs. Buy Problem (1:2) (h30499.www3.hp.com)
- Information Security Awareness Through Analogy (clerkendweller.com)
A Security Policy needs to be abstract not specific
- Image via Wikipedia
There's much I don't like about many of the published security policies an the ones I see in use at many sites I visit and audit. But lets pick on ones that deal with passwords.
Firstly, the concept of passwords are limiting.
Are you going to add a "pass-card policy" and a "iris scan policy" and a "fingerprint policy" ?
Of course not. its all "Authentication".
And it doesn't matter where or how or even WHAT you are accessing - policy applies. So the policy has to be general.
The workshops I've run on policy writing open with an explanation of what makes good and bad policy and use this point as an illustration. Good policy is general and isn't going to need to be revised as business
needs or technology - and hence risk and how its addressed - change.
Access to corporate Information System resources
will be restricted to authorized users in accordance
with their roles. Users will uniquely identify
themselves and will be accountable for the actions
carried out under this identification.
Simple language, very general.
You could say it even applies to the to the parking lot at the data centre.
It doesn't address passwords or swipe cards or fingerprints directly for a simple reason.
THEY ARE NOT POLICY ISSUES.
Le me say that again.
Specific controls and specific control technology are not policy issues.
They are standards.
Refer to them. Refer to NIST, refer to the Microsoft documents.
They are not policy.
The _general_ example I gave above is POLICY.
Can you see the difference?
Now read that paragraph again.
Does it say anything about HOW you access corporate IS resources?
No.
So it doesn't matter if you do it at the computer at your desk in the office; from your laptop when working at home over the VPN; from the airport using your smartphone over the Internet. It doesn't matter if the 'resource' is a parking lot, the email server or in 'The Cloud' somewhere.
You don't need separate policies for all of them.
I picked on 'password policy' because its easy to illustrate how a specific like this is wrong-minded and can easily be invalidated by a shift in technology. But the principle applies to the whole of the proposed document.
Why does this matter?
A minimalist approach has much to recommend it.
Quite apart from making the document shorter an hence easier to communicate, it eliminates redundancy and with it the opportunity for sections that talk about what is essentially the same thing but end up
being contradictory.
The example I gave avoids there being questions like
Does remote access use passwords or certificates?
because its NOT a policy issue. A 'remote access policy' might or might not talk about passwords, about SSH, kerberos or X.509 depending on the the bias of a technical writer. In which case its about standards, not policy, and its about access controls, no policy.
Implementation details - controls - must not be embedded in policy.
There a lot more potential for conflict in the document structure as its laid out at the moment.
Why do I talk about it?
Lets leave a policy document aside or a moment and thing of our jobs as Information Security specialists. part of our roles is thinking about what can go wrong, the weaknesses in the configuration and management of the Information systems, management, communication and storage. We think about threats and vulnerabilities.
Now apply that same approach to the document. this one you are calling a "policy manual". Don't take a bottom-up approach, such as arguing over the length of a password or how often it should be changed. That isn't policy. At best its a standard and a highly context sensitive one at that!
Identify what is in common and make it a policy.
I gave the example above of access control.
It doesn't matter whether its access to the workstation, the server, that CRM database, the "pipe" out to the Internet, or the Citrix array inbound over the 'Net from home or an Internet caf�.
It all access to corporate IS resources. It should have one and only one policy. It should not be spread over a number of policies with ifs and buts and different technologies and phases of the moon.
Remember: you have to write policy that can be followed and can be enforced. If users )or sysadmins for that matter) have to remember lots of different circumstances and special conditions then they are less
likely to conform. "Oh, I forgot"; "Oh, I was confused"; "Oh, I didn't think it applied here"; "Oh, I didn't think it applied to me".
That's a start.
Yes, I've picked on "access", but I could equally well have picked on "virus" or "email" or "mobile".
About Social Networking policy
Policy development is one of my areas of practice, so when a colleague on a mailing list asked about how to phrase policy to deal with the social networks (Facebook, Twitter, Myspace, etc.) and what the "best practices" are, I came out of my shell to reply.
(We'll skip over the oxymoron "best practices" since "Context is Everything".)
The phrase
"Use of corporate resources ..."
is a wonderful one to use to prefix just about any policy statement or justification. In one workshop on policy development that I ran someone pointed out that it applied to access to the company parking lot!
The issue here isn't "social networking", no matter how much the media and ZDNet would have you believe. It boils down to a few very clear and easy to enumerate issues:
About creating Corporate IT Security Policies
As I've said before, you should not ask yourself what policies to write but what you need to control. If you begin with a list of polices, you need to adapt the reality to the list. The risk is that you create a false sense of control of security.
The threat-risk approach is 'technical', and as we've discussed many times, the list of threats cannot be fully enumerated, so this is a ridiculous approach.
Basing policy on risk is also a fruitless approach as it means you are not going to face some important points about policy.
Policy is for people. Its not technical, its about social behaviour and expectations.
Policy can be an enabler, but if you think only about risk you will only see the negatives; your policies will all be of the form "Don't do that".
Policies should tell people what they should do, what is expected of them, give them guidance.
Policies also have to address the legal and regulatory landscape. As such they may also address issues of ethics, which again is not going to be addressed by a threat-risk approach.
All in all, if you follow Mark's advice you may write policies that seem OK, but when it comes to following them it will be like the song from the 70s by The Five Man Electric Band:
Sign Sign everywhere a sign
Blocking out the scenery breaking my mind
Do this, don't do that, can't you read the sign
and people will feel put upon and that the company is playing Big Brother. You will have heavy-handed rules that are resented and not clearly understood by all employees.
Policies are there to control the behaviour of people in the corporate setting. Think in terms of people and behaviour, not in terms of threats and risks.
Policies are to guide and control behaviour of people, not of machines and software.
Think of policies as having these kinds of objectives and you will be on a firm footing:
- Shift attitudes and change perspectives
- Demonstrate management support
- Assure consistency of controls
- Establish a basis for disciplinary action
- Avoid liability for negligence
- Establish a baseline against which to measure performance and improvement
- Coordinate activities
and of course something important to all of us toiling in InfoSec
- Establish a basis for budget and staffing to implement and enforce the policies
Policies need to be created from the point of view of management, not as a set of techie/geek rules, which the threat/risk approach would lead to.
Not least of all because, as I'm sure Donn Parker will point out, managers don't want to hear all that bad stuff about threats; they want policies that encourage staff to contribute to the profitability of the
company.
Related articles
- How to create an effective social-media policy for your company (smartblogs.com)
- 6 Tips For Great IT Security Policies (itexpertvoice.com)
- Helping Employees Get Corporate Security Policy (pcworld.com)
- Creating an Enterprise Employee Social Media Policy (itexpertvoice.com)
Swine Flu Issues – insufficient discrimination
The trouble with some people is that they make some deceptively reasonable comments that don't stand up under critical analysis
With an ailing economy and a whole lot of cancelled contracts resulting from
that poor economy. Pandemic planning is a major threat to our most important
asset people and it appears as though that vulnerability may have been
activated. Its time to dust off the BCP plan and update it with a Pandemic
Mitigation strategy.If it takes a pandemic to motivate you to create or review a BCP then
something is seriously wrong, and it has nothing to do with the pandemic.
Pandemic?
As one manager said to me a long time ago, "show me the numbers".
I read:
The number of confirmed cases rose Monday to 50 in the U.S., the result
of further testing at a New York City school. The WHO has confirmed 26
cases in Mexico, six in Canada and one in Spain. All of the Canadian
cases were mild, and the people have recovered.The Mexican government suspects the virus was behind at least 149 deaths
in Mexico, the epicentre of the outbreak, with hundreds more cases
suspected.
I'm sure just about any ocotr - or the 'Net - can supply us with figures on the cases and deaths from 'regular' flu world-wide, as well as the named versions.
Make your policy generic, not specific
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