Nobody wants to pay for security, including security companies
https://www.linkedin.com/pulse/nobody-wants-pay-security-including-companies-beno%C3%AEt-h-dicaire
In theory, consumers and businesses could punish Symantec for these
oversights by contracting with other security vendors. In practice, there’s
no guarantee that products from other vendors are well-secured, either
— and there is no clearway to determine how secure a given security
product actually is.
Too many firms take an "appliance" or "product" (aka 'technology") approach to security. There's a saying that's been attributed to many security specialists over the years but is quite true:
If you think technology can solve your security problems,
then you don't understand the problems and you don't
understand the technology.
Its still true today.
Data on a Train
http://www.informationsecuritybuzz.com/daily-commute-mean-data/
The latest intelligence on Al-Qaeda, a high profile Child Protection
report and plans for policing the London 2012 Olympics; three very
different documents with two things in common: firstly, they all
contained highly confidential information and secondly, they were all
left on a train.
Or maybe "Strangers on a Train"
Our latest research reveals that two thirds of Europe’s office commuters
have no qualms about peering across to see what the person sitting next
to them is working on; and more than one in ten (14 per cent) has
spotted confidential or highly sensitive information.
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.
“Paid to be paranoid”
Read the first four paragraphs of this:
http://hollylisle.com/shoes-and-handbags/
Forget the rest, forget that its about 'creative writing', just answer that question.
Bruce Schneier among other, myself included, have asked questions like that. Are you 'paranoid' enough to be in the security business?
One of my colleagues, Rob Slade yes *that* Rob Slade when he is teaching in Toronto, usually asks me to come along to talk for an hour to his students about "The CISSP Experience".
The first thing I ask the class is if there are any active or ex-military or law enforcement people present. To date there never have been, and to be honest it leaves me with a bit of a "Bah Humbug!" feeling when the class is really a company stuffing its IT department through the course and exam "for the numbers". Rob has some cynical comments to add but don't forget for him it's a days work and a days pay.
I'm also hit on for a variety of reasons by kids (even postgraduates) who "want to break into" -- yes that's the words they use, ironic isn't it? -- the security business. I suppose because the press makes it look more glamorous than just being a programmer or sysadmin. I keep telling them that its experience that counts, not certifications; too many, especially those from Asia, seem to think that a certification is badge that gets you work. Not so. Mind you, locally the recruiters cant seem to tell what makes InfoSec different from IT. But that's a subject for another time.
And hence the opening lines to Holly's blog.
No, Holly, you're not alone; many true security professionals, be it Infosec, military or law enforcement, think like that.
- What is the 'attack surface'?
- What are the potential threats? How to rate them?
- How can I position myself to minimise the effect of an attack?
- What is the 'recovery mode' (aka: line of retreat)?
If you can't do this, then you shouldn't be in "Security".
How much Risk Assessment is needed?
In many of the InfoSec forums I subscribe to people regularly as the "How long is a piece of string" question:
How extensive a risk assessment is required?
It's a perfectly valid question we all have faced, along with the "where do I begin" class of questions.
The ISO-27001 standard lays down some necessities, such as your asset register, but it doesn't tell you the detail necessary. You can choose to say "desktop PCs" as a class without addressing each one, or even addressing the different model. You can say "data centre" without having to enumerate every single component therein.
At first.
An “11th Domain” book.
http://www.infosectoday.com/Articles/Persuasive_Security_Awareness_Program.htm
Gary Hinson makes the point here that Rebecca Herrold makes elsewhere: 
Awareness training is important.
I go slightly further and think that a key part of a security practitioners professional knowledge should be about human psychology and sociology, how behaviour is influenced. I believe we need to know this from two aspects:
First, we need to understand how our principals are influenced by non-technical and non-business matters, the behavioural persuasive techniques used on them (and us) by vendor salesmen and the media. many workers complain that their managers, their executives seem t go off at a tangent, ignore "the facts". We speak of decisions drive by articles
in "glossy airline magazines" and by often distorted cultural myths. "What Would the Captain Do?", or Hans Solo or Rambo might figure more than "What Would Warren Buffett Do" or "What Does Peter Drucker Say About A Situation Like This?". We can only be thankful that most of the time most managers and executive are more rational than this, but even so ...
How to build an asset inventory for 27001
How do you know WHAT assets are to be included in the ISO-27K Asset Inventory?
This question and variants of the "What are assets [for ISO27K]?" comes up often and has seen much discussion on the various InfoSec forums I subscribe to.
Perhaps some ITIL influence is need. Or perhaps not since that might be too reductionist.
The important thing to note here is that the POV of the accountants/book-keepers is not the same as the ISO27K one. To them, an asset is something that was purchased and either depreciates in value, according to the rules of the tax authority you operate under, or appreciates in value (perhaps) according to the market, such as land and buildings.
Here in Canada, computer hardware and software depreciates PDQ under this scheme, so that the essential software on which you company depends is deemed worthless by the accountants. Their view is that depreciable assets should be replaced when they reach the end of their accounting-life. Your departmental budget may say different.
Many of the ISO27K Assets are things the accountants don't see: data, processes, relationships, know-how, documentation.
Why Info Sec Positions Go Unfilled
http://www.infosecleaders.com/2012/05/career-advice-tuesday-why-info-sec-position-go-unfilled/
There are many holes in this, but I think they miss some important points.
First is setting IT HR to look for Infosec.
That is because many people think InfoSec is a IT function as opposed to an organizational function. This goes in cycles: 20 years ago there was the debate: "Should Infosec report to IT?" The overall decision was no;. Infosec might need to 'pull the plug' on IT to protect the organization.
Second there is the vast amount of technology claiming to do InfoSec.
It is all network (and hence IT) as opposed to business fulfilment. This has now spread to "Governance". You can buy governance software. What does this do for the ethical outlook of the executive, the board and management? How is Governance tied to risk management and accountability and visibility by this software?
Technology won't solve your problems when technology *is* your problem.
InfoSec is about protecting the organization's information assets: those assets can be people, processes or information. Yes technology may support that just as technology puts a roof over your head (physical security) and somewhere to store the information. Once this was typewriters, and hand-cranked calculators and filing cabinets, and copying was with carbon paper. The technology may have changed but most of the fundamental principles have not. In particular the ones to do with attitudes and people are the same now as they were 50 or 100 years ago.
Related articles
- Bruce Schneier on the mic: InfoSec 2012 (blog.bt.com)
- InfoSec Sniffs Out Security Risks (prweb.com)
- Incomplete Thought: Offensive Computing - The Empire Strikes Back (rationalsecurity.typepad.com)
- The Infosec Investment Equation: Can You Solve It?... (neirajones.blogspot.com)
- Myth or Fact? Debunking 15 of the Biggest Information Security Myths (tripwire.com)
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!
Which Risk Framework to Use: FAIR, FRAP, OCTAVE, SABSA …
What framework would you use to provide for quantitative or qualitative risk analysis at both the micro and macro level? I'm asking about a true risk assessment framework not merely a checklist.
Yes, this is a bit of a META-Question. But then its Sunday, a day for contemplation.
When does something like these stop being a check-list and become a framework?
COBIT is very clearly a framework, but not for risk analysis and even the section on risk analysis fits in to a business model rather than a technology model.
ISO-27K is arguably more technology (or at least InfoSec) focused that COBIT, but again risk analysis is only part of what its about. ISO-27K calls itself a standard[1] but in reality its a framework.
The message that these two frameworks send about risk analysis is
Context is Everything
(You expected me to say that, didn't you?)
I'm not sure any RA method works at layer 8 or above. We all know that managers can read our reports and recommendations and ignore them. Or perhaps not read them, since being aware of the risk makes them liable.
Ah. Good point.
On LinkedIn there was a thread asking why banks seem to ignore risk analysis .. presumably because their doing so has brought us to the international financial crisis we're in (though I don't think its that simple).
The trouble is that RA is a bit of a 'hypothetical' exercise.
Mistaken Thinking – Risk not threats
Image via Wikipedia
Via a LinkedIn posting in the Infosecurity magazine forum titled
"Internet Threats Posed By Mobile Devices: How Can We Prevent Them?"
I came to
http://www.mxsweep.com/blog/bid/65075/Internet-Threats-Posed-By-Mobile-Devices-How-Can-We-Prevent-Them
OUCH OUCH OUCH!
The mobile devices don't pose threats.
The mobile devices represent risks.
Threats are external. They are not under your control.
The article title is clearly confusing THREATS with RISKS.
There are aspects of risks which ARE under your control.
You can control how EXPOSED you are to threats and how they will IMPACT you - or more specifically your assets. In this case the mobile devices.
You can't prevent threats, you can only mitigate their IMPACT.
You can instigate preventive measures.
Mobile devices and the data on them are ASSETS, not threats.
Correct terminology leads to correct thinking.
Eliminating misunderstanding and confusion leads to effective results.
Related articles
- The threat facing Android (Hint: It's not Apple) - Fortune Tech (tech.fortune.cnn.com)
- Mobile threats increased during first half of 2011 (preternaturalpost.com)
- 5 Ways To Fight Mobile Malware (informationweek.com)
- Malware risk on Android devices growing, report says (sfgate.com)
- Mobile Device Security: Questions to Ask for Creating Policy (pcworld.com)
- Mobile app malware menace grows (go.theregister.com)
- Securing Mobile Devices (enhancedtech.wordpress.com)
- Cyber criminals targeting mobile devices (premierlinedirect.co.uk)
All Threats? All Vulnerabilities? All Assets?
One list I subscribe I saw this outrageous statement:
ISO 27001 requires that you take account of all the relevant threats
(and vulnerabilities) to every asset - that means that you have to
consider whether every threat from your list is related to each of
your assets.
"All"? "Every"?
I certainly hope not!
Unless you have a rule as to where to stop those lists - vectors that you are going to multiply - are going to become indefinitely large if not infinite. Its a problem in set theory to do with enumberability.
See
http://infosecblog.antonaylward.com/2010/05/19/the-classical-risk-equation/
for a more complete discussion of this aspect of 'risk'.
See
http://www.bloginfosec.com/2010/08/23/why-the-risk-threats-x-vulnerabilities-x-impact-formula-is-mathematical-nonsense/
in which Jeff Lowder has a discussion of the "utility value" approach to controls
Because its the controls and their effectiveness that really count.
Career Insights from Stephen Northcutt, CEO of SANS
http://www.bankinfosecurity.com/articles.php?art_id=2914 
Fascinating.
I get a lot of enquiries from wannabes who, as they put it, want to "break into security". I presume they see it as more interesting than the work they are doing.
They come in all varieties, from high-school kids asking about what degree they should take to people with no actual work experience asking if they should take a CISSP or CISM.
The luminaries of our profession, be they CISSPs or people like Marcus Ranum and Bruce Schneier who lack such certifications, all came up the same way that Stephen Northcut did and many of us here did - the long way. And gained the practical experience and understanding of the issues along the way.
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 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)
8 Dirty Secrets of the IT Security Industry – CSO.com
Image via Wikipedia
Do make note of points 1,3, and 6.
I particularly appreciated the subtext of the wording of #1.
Vendors don't need to be ahead of the threat, just the buyer.
We all know the story of the two campers and the bear, but this is an interesting variation. We've just discussed Mr Carr screaming about how he wasn't told by his security staff that there were more threats.
Yes but ... Its not the security staff that set the budget or make the buying decisions. Look: it says "buyer", not "customer".
How often have you had your security advice over-ridden for anyone of a number of reasons? Its not you doing the BUYING is it.
And why do you think that the saleswomen wear suits and talk in that stupid language using terms like "solution" (oh-ho, watch out, here comes Les...) and "bottom line" and other stuff that has nothing to do with InfoSec.
'Cos it isn't YOU doing the buying.
At best they throw you a bone since you might be an 'influencer' - more salesman-speak. (But 'influencer' is too close to 'influenza' which is why they don't get too close to you...)
Mean while, you're talking to your manager about all these nasty things like threats and the possibility of embarrassment in the press and lawsuits, while that nicely dressed saleslady is talking sweetly about nice things such as profit and success and such like.
Image via Wikipedia
Lets face it, the game is semantically rigged against us.
"Given a choice between dancing pigs and security, users will pick dancing pigs every time."
"Oh look http://pics4.city-data.com/cpicc/cfiles34082.jpg hey, that's neat, I didn't know they could do that...."
Related articles
- InfoSec In The Supply Chain (blogs.forrester.com)
Does the Certified Ethical Hacker add value to a CISSP
A young colleague asked about the value of the CEH certification. Would it "Add Value" to his existing CISSP? The syllabus looked interesting to him and he wondered how prospective employers would view this.
This was my reply:
There are TEN domains to the CISSP's CBK. People come to security from
many walks of life and fields of endeavour and information security has
many facets beyond protecting networks and hosts from malicious attack.There have been times in my career when the work covered by the CEH
would have been relevant, but back then neither the CEH not the CISSP
existed. But even back then I realized that the real problem was not
the networks or the hosts or the system administrators.Each decision you make, each certification and specialization you focus
on leads you down a career path. I've often criticised "reactive mode"
security. The same I'd apply to your career. Is this a proactive move?
Is there a career plan here? Where do you see yourself in five or ten
years? How long do you expect to be doing Pen Testing?Many of us took the CISSP not as a learning exercise but to validate our
already existing skills and experience. You can read in the archives
tales of people at the seminars that pre-dated "boot camps" who wrote
the books that the exam questions were based on. I mention this
because of the way you have worded your question. Are you interested in
the CEH as a validation of your experience or do you expect the course
to teach you Pen Testing? If the latter, then I'd think again.But ultimately it boils down to the issue of your career. Many of the
older members of this forum, and older CISSPs in general, have very
diverse backgrounds. There is an old joke about a Phd being a 'delta
function', you know more an more about less and less. Many career moves
are like that. I mention this because I, and others, feel there is a
point in a career where it is the width of experience, the 20-20
peripheral vision, the understanding of context, the ability to avoid
Errors of the Third Kind, that employers value.Yes, it depends on your age - which you didn't mention - and other
factors. Context is, as I keep saying, everything.Maybe one day I'll go back an finish my degree in Social Anthropology.
All in all I feel understanding people and the social dynamics of
organizations is more relevant to communicating and effecting the
changes needed to bring about good security practices. But that's me,
my context an my career objectives.You need to make it clear what are yours before you can say whether a
CEH - or any other certification for that matter, is relevant to you.
As Robert Heinlein said:
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
Related articles by Zemanta
- Society of Payment Security Professionals Welcome 50 New CPISM/CPISA's (pindebit.blogspot.com)
- Ethical Hacking: Beat Hackers At Their Own Game (shegeeks.net)
- "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship,..." (secretenemyhideout.com)
- Ethical Hacking - Beating Bad Guys for Fun & Profit (giveaway) (geekmommy.net)
- Sci-fi writers take US security back to the future | Jenna Lang (guardian.co.uk)
- Get Paid To Hack (joetech.com)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=720c466d-6acc-4639-8721-a1f99719a911)