The InfoSec Blog

http://www.nytimes.com/2012/04/03/opinion/how-china-steals-our-secrets.html

This is better written than most ‘chicken little’ pieces, but please can we have ‘history’ of how most nations, including the USA, have engages in ‘industrial espionage‘.

I recall a presentation by CSIS that was making the point that Canada’s greatest threat on the Industrial Espionage scene was France, and France had been practising Industrial Espionage against the “English Speaking World” for centuries. And he had evidence to back that up from at lest Napoleonic times.

But then don’t forget that the “English Speaking World” stole such secrets from China as “Tea“:

For centuries, the secret of growing tea was one of China’s
most closely-guarded treasures. Along with silk, tea was an
extremely valuable agricultural commodity, prized as a luxury
item across Asia and into Europe.

In the mid-19th century, however, Briton Robert Fortune
dressed as a Chinese man (complete with queue) and set out
to discover the secret of tea-growing. He located the bushes
that produce tea, and stole seedlings that he transported to
British India. China’s tea monopoly was broken.

Robert Fortune (1812-1880) (Photo credit: Wikipedia)

Fortune’s explorations are detailed in a new book, For All
the Tea in China, by Sarah Rose. She frames this not
simply as a tale of Victorian exploration, but as early
industrial espionage – which, of course, it was.

I’m not saying this justifies anything, any more that the Opium trade or forcing products from the Industrialized West onto Asian markets, also part of or common historic context, justifies any reprisals.

I’m just saying Context is Everything and if you ignore history (especially when dealing with people for whom history is an important context) then you are setting yourself up for a sea of troubles.

Related articles

• For All The Tea In China – Sarah Rose (scottjb.wordpress.com)
• Different Ethical Issues Faced by the Global Software Companies (thinkingbookworm.typepad.com)
• Howes calls for cyber espionage inquiry (news.smh.com.au)
• Corporate Espionage Is Real – Even In The Pharma Industry (bioresearchonline.com)
• “Cyber Czar” wants Homeland Security to patrol America’s Internet borders (blacklistednews.com)
• Former Pentagon Official Says All Chinese Electronics In The US Could Have Built-In Trapdoors (businessinsider.com)
• FBI: Economic Espionage (gloucestercitynews.net)
• Trade Secrets and The Economy (psliplaw.wordpress.com)
• Richard Clarke: China has hacked every major US company (zdnet.com)
• FBI cracks down on economic espionage (wjla.com)
• Peter Thomas Senese’s THE DEN OF THE ASSASSIN Is A Geopolitical Financial Espionage Thriller Thrust In The World Of Cyber, Biological and Chemical Warfare (prweb.com)
• Chinese Economic Espionage: An Overlooked Concern (heritage.org)

Last month, this question came up in a discussion forum I’m involved with:

Another challenge to which i want to get an answer to is, do developers
always need Admin rights to perform their testing? Is there not a way to
give them privilege access and yet have them get their work done. I am
afraid that if Admin rights are given, they would download software’s at
the free will and introduce malicious code in the organization.

The short answer is “no”.
The long answer leads to “no” in a roundabout manner.

Unless your developers are developing admin software they should not need admin rights to test it. Read the rest of this entry »

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! Read the rest of this entry »

On the ISO27000 Forum list, someone asked:

I’m looking for Risk statement for each ISO 27k control; meaning
“what is the risk of not implementing a control”.

That’s a very ingenious way of looking at it!

One way of formulating the risk statement is from the control
objective mentioned in the standard.
Is there any other way out ?

Ingenious aside, I’d be very careful with an approach like this.

Risks and controlsare not, should not, be 1:1.

The Risk Management Process for IT Systems according to ENISA, following ISO 27005 (Photo credit: Wikipedia)

Some controls are there to support other controls. And don’t forget that some controls are detective and a control that ‘detects’ the functioning of another control is perfectly valid.

We’ve often spoken of “baseline controls”, that is controls which should be in place “regardless”. Well OK, context matters. The baseline for a bank and there baseline for a power plant will differ, but they will also have a lot in common. One common branch might be a yes response to ‘are you connected to the Internet?’

A “Yes you are connected to the Internet” will produce a plethora of threats (note: *threats* not risks!) that will keep you busy all month working through to determine the risks, and for almost all of them the control will be “configure the firewall…”.

You do have a firewall as part of your baseline, don’t you?
(And you took it out of the box and installed it at a choke point, didn’t you?)

Another issue that often come up on this forum is that of assets.
Now if it was me, I’d start with the assets. There are a number of reasons for that. First and foremost, this is all about protecting those assets. They are also a lot easier to identify than threats or vulnerabilities

So we get back to “what is the risk of not implementing a control”.
The control objectives are, ultimately, to protect the assets, by various means. So you need to ask that question in terms of the assets.

Another way of looking at it is enumerate the assets and enumerate the controls and establish the relationships. Are there assets that don’t have controls protecting them?

diagram showing threat agents, attack vectors, weakness, controls, IT asset and business impact (Photo credit: Wikipedia)

I admit there is more to it than that; controls may be inadequate or superfluous. There is a tendency to implement easy ones.

Donn Parker has written some excellent papers on selecting controls.
They were published in the ISSA Journal back in 2010.

http://www.google.ca/search?q=parker+%22Security+Control+Selection+Principles%22

Related articles

• Is ISO 27001 Worthwhile for Your Business? (deurainfosec.com)
• Final results of COSO vs ISO risk management survey (normanmarks.wordpress.com)
• ISO 27001: An overview of ISMS implementation process (net-security.org)
• ISO 27001 and BS 25999-2: Why is it better to implement them together? (net-security.org)

You do do backups don’t you?  Backups to DVD is easy, but what software to use?

Why not simply k3b ?

But if it some down to it, there’s a decision tree you can and should work though.

• Do you want the DVD backup ‘mountable’?
  If it is then you can see each file and selectively restore using the normal file management tools (cp, rsync etc)
  If you use some sort of ‘dump’ format (tar, cpio, zip or proprietary) then you will need the corresponding tool to access the backup

My choice, based upon both K.I.S.S. and bitter experience is to go with the mountable.

• - How are you ‘snapshoting’ your files?
  If you are backing up a live system[1] then there is the risk that the backup is out of phase with itself as files get changed during the time it takes to make the backup.

My solution to this is to use the snapshot mechanism of LVM.

• - How are you managing the backup archives?
  Do you need a specific dated version of a file or directory?
  Would a VCS be more appropriate than a backup system?

Sometimes you need both. I maintain changes to config (mainly in /etc/) with a VCS – AND take periodic snapshots.

• Ultimately its not about making backups, even if that seems to be the
  most of the work, but the ability to restore.

A client found it easier to take whole image backups but once when having to restore a single file there was a finger-slip and he restored the complete machine state of three years previously, loosing all that days work plus the next day when the machine was out of service being restored to the last (previous) backup. The moral here is that your RESTORE strategy, as determined by your normal business functions and NOT by the convenience of the IT department, should determine your backup strategy.

• - How “automated” do you want this backup to be?
  Sometimes you’ll find the automation tail wags the normal operation dog.

My use of K3B means I do disk-to-disk-to-DVD. (Using LVM’s snapshots)
It also means I structure my file systems so that they can be imaged onto a DVD. It means I can retrieve single files or mount the DVD and use it in place of the file system. It also means that I can create arbitrary backups, cherry-picking the files and folders to backup.

I realise this is going to be inappropriate for many sites and business functions.

This is why I STRONGLY suggest that instead of simply asking for suggestions you work through what are the key, the critical and the nice-to-have features of your backup AND RESTORE functionality.

Any package you might choose is going to have constraints and assumptions about The Way Things Are. You need to be aware of those and need to consider if they fit in with The Way You Work. A backup system that works well for a data center of ISP might be totally inappropriate and troublesome for a SMB.

[1] Once upon a long time ago systems were shutdown or all jobs
suspended for the backup. This has disrupted projects for me a number
of times.

The hack to make the HP printers burn was interesting, but lets face it, a printer today is a  special purpose computer and a computer almost always has a flaw which can be exploited.
In his book on UI design “The Inmates are Running the Asylum”, Alan Cooper makes the point that just about everything these days, cameras, cars, phones, hearing aids, pacemakers, aircraft, traffic lights … have computers  running them and so what we interface with is the computer not the natural mechanics of the device any more.

Applying this observation makes this a very scary world. More like Skynet in the Terminator movies now that cars have Navi*Star and that in some countries the SmartStreets traffic systems have the traffic lights telling each other about their traffic flow. Cameras already have wifi so they can upload to the ‘Net-of-a-Thousand-Lies.

Some printers have many more functions; some being fax, repro, and scanning as well as printing a document.   And look at firewalls. Look at all the additional functions being
poured into them because of the “excess computing facility” – DNS, Squid-like caching, authentication …

I recently bought a LinkSys for VoIP, and got the simplest one I could find. I saw models that were also wifi routers, printer servers and more all bundled onto the “gateway” with the “firewall” function. And the firewall was a lot less capable than in my old SMC Barricade-9 home router.

I’m dreading what the home market will have come IP6

I recall the Chinese curse: yes we live in “interesting security issue” times!

But in the long run of things the HP Printer Hack isn’t that serious.   After all, how many printers are exposed to the Internet.    We have to ask “how likely is that?”.
Too many places (and people) put undue emphasis on Risk Analysis and ask “show me the numbers” questions. As if everyone who has been hacked (a) even knows abut it and (b) is willing to admit to the details.

No, I agree with Donn Parker; there are many things we can do that are in the realm of “common sense” once you get to stop and think about it. Many protective controls are “umbrellas”, that its about how you configure your already paid-for-and-installed (you did install it, didn’t you, its not sitting in the box in the wiring closet) firewall; by spending the money you would have spent anyway for the model that has better control/protection — you do this with your car: air-bags, ABS and so on so why not with IT equipment? The “Baseline” is more often about proper decisions and proper configuration than “throwing money at it” the way governments and government agencies do.

In case you’re not aware, ISECOM (Institute for Security and Open Methodologies) has OSSTMM3 – The Open Source Security Testing Methodology Manual – http://www.isecom.org/osstmm/

There’s an interesting segue to this at
https://www.infosecisland.com/blogview/14651-How-to-Pen-Test-Crazy.html

Skip over his ranting about the definition of “hackers”

This is the meat:

Wewrote the OSSTMM 3 to address these things. We knew that penetration

OSSTMM Logo

testing the way it continued to be marginalized would eventually hurt
security. Yes, the OSSTMM isn’t practical for some because it doesn’t
match the commercial industry security of today. But that’s because the
security model today is crazy! And you don’t test crazy with tests
designed to prove crazy. So any penetration testing standard, baseline,
framework, or methodology that focuses on finding and exploiting
vulnerabilities is only perpetuating the one-trick pony problem.
Furthermore it’s also perpetuating security through patchity, a process
that’s so labor intensive to assure homeostasis that nobody could
maintain it indefinitely which is the exact definition of a loser in the
cat and mouse game. So you can be sure it also doesn’t scale at all with
complexity or size.

I’ve been outspoken against Pen Testing for many years, to my clients, at conferences and in my Blog. I’m sure I’ve upset many people but I do believe that the model plays up to the Hollywood idea of a Uberhacker,
produces a whack-a-mole attitude and is a an example of avoidance behaviour, avoiding proper testing and risk management such as incident response good facilities management.

I’ve seen to many “pen testers’ and demos of pen testing that are just plain … STUPID.  Unprofessional, unreasonable and pandering to the ignorance of managers.

In the long run the “drama-response” of the classical pen-test approach is unproductive. It teaches management the wrong thing – to respond to drama rather than to set up a good system of governance based on policy, professional staffing, adequate funding and operations based on accepted good principles such as change management.

And worse, it

• shows how little faith your management have in the professional capabilities of their own staff, who are the people who should know the system best, and of the auditors who are trained not only in assessing the system but assessing the business impact of the risks associated with a vulnerability
• has no guarantees about what collateral damage the outsider had to do to gain root
• says nothing about things that are of more importance than any vulnerability, such as your Incident Response procedures
• indicates that your management doesn’t understand or make use of a proper development-test-deployment life-cycle

Yes, classical hacker-driven pen testing is more dramatic, in the same way that Hollywood movies are more dramatic. And about as realistic!

“Crazy” is a good description of that approach. Read the rest of this entry »

A business might possibly choose not to have a BCP but they might be interested in doing a BIA
After all, the “impact” might be something positive resulting from some change.

Oh, the Irony!
Expeditious and cost effective.

I’ve audited BCPs and always found them lacking. They are difficult to build and often make assumptions that are necessary to get the plan done but are unreasonable in reality. Read the rest of this entry »

In a discussion of Open Source vs Closed Source/Commercial …

Voice 1: Maybe because they’re not customers? (in the paying for a service sense)
Voice 2: Well, I don’t understand that model. I expect to pay for code that someone writes because otherwise I cannot expect someone to stand by the stuff when it doesn’t work.

Ironically I’ve never found that to be the case.

The stuff I pay for, cable service, hosting; and the stuff I use that someone else pays for (i.e the people I work for), commercial hardware, software and service; are the other way round to what you might think.

The support sucks! Read the rest of this entry »

If there’s one thing that upsets me when I see articles and posting to forums about policy, its mention of a “Password Policy”. I have to step away from the keyboard, go outside and take some deep breaths to calm down.

I get upset because policy is important and developing — and more importantly communicating — policy has been an important part of my career and the professional service I offer. Policies need to be easy to understand and follow and need to be based on business needs.

If you begin with a list of policies, you end up adapting the the reality of your business – the operations – to the list. You are creating a false sense of security. You need to address what you need to control, and that is Identity and Access.

Lets face it, passwords, as Rick Smith points out in his book “Authentication“, are not only awkward, they are passée – even Microsoft thinks so. More to the point, using passwords can be bad for your financial health.

They should be used with care and not as a default.

And they should most certainly NOT be entombed in a corporate policy statement. Read the rest of this entry »

A member of a discussion list I subscribe asked for a Firewall Policy template.

A usual, I was alarmed enough by this to want to comment and drag it back to the discussion on “assets”.

I don’t think you should have a “Firewall Security policy”.
This is why.

A great book on firewalls once described the firewall as

The network’s response to poor host security

You can occasionally see articles on host-centric security drifting by …

A firewall is a “network PERIMETER protection device”.

Do you have a well defined perimeter to which you can apply enforcement policies, or is your ‘perimeter’ like so many businesses these days, a vague and nebulous concept that is weakly defined? One thing that is “in” these days is “De-perimiterization“. See “The Jericho Forum“.

The firewall model is inherently one of a ‘hard outer shell and soft vulnerable centre’. As I said, its based on the idea of poor host security. Good host security will mean that the hosts don’t have any un-necessary open ports. Scan you network. If there are no open ports why do you need a firewall?

Oh, right: port 80. And all the hundreds of services behind it.
In effect those are your ‘open ports’. Yes, there are firewalls that claim to do ‘deep packet inspection’.  Check what they actually do.

There are other uses for a firewall?   Well some people use it as a NAT device. Some people use it to control outbound connections – “data leakage”.   What they are really saying is that they haven’t built their information architecture in a robust and secure manner.  Back to the ‘poor host security’.  Perhaps you should be doing this sort of thing in your switch or router with ACLs.  Partition your network.

So why did I start by saying “assets”?
Some people think that the assets are the hardware.
Focusing on the hardware as opposed to the services, the information and the processes leads you to think in terms of things like ‘firewalls’ rather than in abstracts like “perimeters” and “access controls”.

By addressing a “Firewall policy” you are focusing on equipment rather than fundamentals.

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”.

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: Read the rest of this entry »

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)

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 Read the rest of this entry »