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.
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.
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
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.
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.
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.
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 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.
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
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.
for a more complete discussion of this aspect of 'risk'.
in which Jeff Lowder has a discussion of the "utility value" approach to controls
Because its the controls and their effectiveness that really count.
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?
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
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".