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.
Surely compliance is binary?
Call me a dinosaur (that's OK, since its the weekend and dressed down to work in the garden) but ...
Surely COMPLIANCE is a binary measure, not a "level of" issue.
You are either in compliance or you are not.
As in you are either deal or alive.
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.
Compliance? What Compliance?
Image via Wikipedia
Sometimes I wonder why we bother ...
Related articles
- Recently Updated "Securities Law Deskbook" - A Resource to Help Achieve Compliance and Avoid Regulatory Problems, From Bradford Publishing Co. (prweb.com)
- SEC: Bigger potential payouts for whistleblowers (marketwatch.com)
- LATEST FEATURE: Compliance: A hybrid marital troika? (ecmplus.wordpress.com)
Separation of Duties: InfoSec, IT and Audit
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:
- IT "makes it so"
- Audit makes sure that they did.
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.
| You: | See that firewall? |
| IT: | Yea, what about it? |
| You: | Its on the network, right? |
| IT: | Yea, where the f*** do you think it should be? You bu**ers are always interfering. |
| You: | And you guys take care of the network and stuff on the network? |
| IT: | When you bu**ers don't interfere. |
| You: | Well we're not going to. Its yours. We won't touch it. We won't go off and buy stuff and put it on your network. |
| IT: | Are you serious? |
| You: | Yes. |
| IT: | Can I have that in writing? |
| You: | Yes. I'll copy you on the roles & responsibilities and separation of duties documents. As well as the policies, compliance and audit requirements. |
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
(Another time I'll discuss the stupid idea that some people in the recruiting profession have that because 'consultants' don't occupy a line-management role that they have 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 in the business and to make sure that the IT department is serving the needs of the business and not just collecting expensive "Toys For Boys".
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 estimations on a paper napkin), wrote up a requirement and handed it over to the people with a Picard-like order to "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, these 'separation of duties', that things get upset.
Related articles
"Paid to be paranoid"(infosecblog.antonaylward.com)
