Don't forget the "A"

IT Security is often described as the assurance of three qualities: Confidentiality, Integrity and Availability. CIA. The "C" is easy to understand, especially since so many organisations have been so helpful by their lack of it, so that we can all point and gawp at massive data losses (while secretly crossing our fingers and hoping the bad guys don't look our way).

Integrity is also easy to understand, and I've blogged before that this was the focus of IT Security efforts when I began my career in the 80s. "C" was hardly talked about, the internet was just an academic plaything back then so we didn't have any public attack surface, thus the only threats were within. The only attack my early employers could envisage was an unauthorised data edit, or perhaps an accidental modification or deletion. Thus we had lots of "I" control.

What of Availability? The "A" of the triad is often the poor relation, many have trouble considering it part of Security in the first place. Surely Availability is part of Service Management, of Disaster Recovery or Business Continuity? Well, yes, but all of those disciplines tend to kick in *after* the service goes down, the first line of defence has to be Security. If you can't apply that change with your day job account, you can't apply those untested code changes and break the system. But perhaps more obviously there is one threat, an attack methodology whose focus is just that single quality. Hitting "A" is the sole objective of the Denial of Service (DoS) attack.

DoS attacks (they are all DoS's but only DDoS's if large numbers of network nodes participate) have exploded in recent years, perhaps due to the perfect storm of ubiquitous internet access, easy availability of simple toolkits with which to launch attacks and political unrest and social disaffection thanks to the global recession. While we security professionals need to do all we can to defend against loss of "A", this article by Dr. Anton Chuvakin points out, among other things, that of the three qualities, Availability is probably the easiest breach to cost, since downtime of your core service usually has a simple economic metric!

But the point of this article is to draw attention to another point Dr Chuvakin makes, almost buried in that blog post, which is this. If Security includes Availability, and Availability is key: why not host your services in a large, redundant, elastic, multi-homed server farm for maximum protection?

Cloud, anyone?

Compliance isn't everything.

What Good is PCI-DSS? from Infosec Island.

More evidence that Compliance should never be equated with Security. There are three issues to my mind:
1. "Point in time" compliance, that is that you're Compliant at the date of the Assessment, but once the auditors have gone, if you don't have Continous Controls, you can drift from that position quite rapidly.
2. Quality of Assessment, i.e. a bad QSA or a good one with bad advice can assess positively in error. And the organisation has no interest in a negative result so will do all they can to gain a pass. The result is false positives.
3. The Human Factor. As the linked piece says.. "No matter how much technology you throw at security, people will always be the weakest link. The PCI-DSS standard (and many others) doesn't do a very good job of evaluating how well we train our people to recognize social engineering and spear phishing."

As I've said before, compliance is not security, but if you do security right, you'll achieve compliance. Get your horse in front of your cart. And manage that Human Factor.

Life in the old AV yet.

Infosec Island: Why We Still Need Firewalls and AV

Just because they're not covering much of the attack space any more, doesn't mean they're not doing a job. Just because your car is now kept in the garage doesn't mean you forget to lock it. Why traditional commoditised controls are still useful, from Infosec Island.

BYOD - not if, but when.

If your business is still locked into the "corporate desktop" model, you are losing competitive advantage over more creative approaches to device management in your organisation such as "Bring Your Own Device", while also ignoring the risk of BYOD already happening "under the radar" right now.

According to IBM, "Forbidding these devices from the enterprise might seem like a great option, but it's rarely effective. No matter how stringent the rules, some employees will fail to comply and put the organization at risk."

But the most telling rebuke for the CIOs that still think they are doing their business a favour by resisting own devices in the workplace is this survey from Decisive Analytics which says "Almost half of the [440] IT executives questioned in this study said BYOD gave their firm a competitive advantage, while almost 70 percent of CEOs were sure of the competitive advantage." Part of this competitive advantage comes from not paying for the devices, for staff training in the corporate apps, and from IT support savings; But more importantly some is down to the capabilities of the devices themselves, and the productivity that comes from letting the user select the device and apps that they like best. If someone can knock up a slideshow using Keynote on an iPad during a 1 hour train journey, why force them to spend 2 days wrestling with Powerpoint on their work laptop?

But if you're still wedded to the idea that a managed corporate desktop is more secure than a solution that involves your salesforce using their own iPads and Netbooks, think again. Polymorphic malware is making traditional anti-virus and anti-spyware controls inneffectual and the software to defend against it is becoming bloated and slowing down old PCs. There's nothing worse than security software that visibly slows the workstation. Except for security software that visibly slows the workstation and doesn't catch the malware anyway.

A new approach to IT architecture involving cloud-delivered services accessed via approved apps on the users own devices can deliver cost savings and increased security. But more importantly, the business wants it. So we'd better stop holding on to 90s thinking and figure out how to deliver it securely.

The Cloud Security Standard is out, and the ISO27001 author is unhappy.

What tangled webs we weave -David Lacey. Quotes from David Lacey's latest criticism of the "standards industry" include: "The standard [which became ISO27002] aimed to remove 90% of the effort in risk assessment by documenting commonly applied controls. Unfortunately it was hijacked by a consultancy community who subsequently reintroduced the need for mandatory risk assessment. It was also intended to be sufficiently broad and deep to minimise the need for any further standards. Yet two decades on, it has inspired a family of dozens of near identical standards and guidelines.". What has sparked Lacey's ire is the Cloud Security Standard. At 176 pages: "The real challenge however will be to turn this impressive body of knowledge into something of practical use to busy security managers. "


There is a reason I called this column "Practically Secure". Because I know how Mr. Lacey feels. Pragmatism is way down the list of objectives for the authors of today's security standards.


[NB I have finally edited this post to add my commentary, sorry for the delay!]

LulzSec - a wake up call?

Conflicted about "hacktivist" activity such as the current actions of LulzSec and Anon? There appears, anectodally to be widespread public support (or at the very least, an absence of unequivocal condemnation) of these semi-organised hacking groups, who seem able to bring down online services at a whim. And a layman's belief that they must have some serious kit, expert knowledge and access to enormous resources, right? According to Sophos Labs Naked Security blog, nothing could be further from the truth:

"LulzSec website break-ins look to have been languorously orchestrated, using nothing more sophisticated than entry-level automatic web database bug-finding tools, available for free online.
In other words, LulzSec is a timely wake-up call to better security if you are still asleep at the wheel. Your customers' data is important - both to them and to you."

We InfoSec professionals need to heed the warning. It's going to get worse before it gets better. The Advanced Persistent Threat is actually the "Simple Persistent Threat". The online organisation without any weak spots, the impregnable network is a fantasy. We need to wake up, improve security but also reduce the potential impact of a breach, with encryption, data cleansing and segregation, and a decent Incident Response plan.

But for now, back to Sophos' take on LulzSec, for those that are ambivalent to their activities:-

"But the end doesn't justify the means. Time spent throwing bricks through other people's digital windows doesn't actually teach anyone anything about glassmaking, glazing or civil engineering. If you consider yourself a hacker and you have time to spare, but you're tempted by "hacking" such as DDoSes or gratuitous break-ins, why not use your skills for active benefit instead? Follow the lead of a guy like Johnny Long and hackersforcharity.org"

David Lacey lays into Compliance. Again!

He co-authored BS7799, the forerunner of the now trendy ISO27000 family of documents that describe best practices in Information Security Management. And now he has disowned his own creation as not fit for purpose in the modern age. In his latest blog post The Three Faces of Information Security, David Lacey goes further and decries all compliance thus:-

"Unfortunately, it's all based on collections of ancient practices, with a heavy emphasis on documentation and audits. And if you don't want to pay for security, you simply accept the risk. Your security might be completely ineffective but your paperwork will gain you full marks."

Lacey then goes on to describe "Real Security" as distinct from both compliance and the "business enablement" view of security we sell to management. With a doom and gloom conclusion that "most organizations are sleepwalking into a future crisis" Lacey paints a grim picture of the current state of Information Security.

Is he right? Certainly the continuous stream of breach notifications and ever growing landscape of threats seems to bear this out. We once knew what we were dealing with, or at least thought we did. We don't, not if we are relying on standards written in the 80s and revised six years ago when the term "cloud computing" was still met with giggles and shrugs and "virtualisation" was a software tool fit only for development environments. The future of Infosec demands imagination, foresight, a step change fit for the 201Xs just as BS7799 was a step change in the 1980s. Because the if current trends show anything, it's that we're even worse prepared against the enormous imagination and technical skill of todays malicious agents than we thought we were. But in truth, no more than we deserve to be.

Human Nature. Friend, not Foe?

A good education programme is worth a dozen new technical controls.

In 2007, details of 25 million UK citizens went missing on two CDs because a junior employee didn't know the rules and management procedures were lax. Similar mistakes led to huge data losses in more recent years at Zurich insurance, UK railways operator Network Rail and the British Ministry of Defence.

One possible response to these breaches is a technological one. Maybe Data-Loss Prevention technology could have helped, even something as simple as disabling the writable DVD drive on employee workstations. If the employee could not copy data to DVD they could not have lost it.

But are we missing the point? These were human failings. Like many security issues these were entirely preventable human errors. A system of people is capable of a myriad different failings. If we continue to throw expensive technological solutions at human error then we will never be finished. Wouldn't we feel better knowing that our employees know what is expected of them in the fight to remain secure and compliant? That they are on the side of Information Security and they work with us to prevent fraud, loss and service disruption?

This is what a security awareness programme does. A good one will change people's understanding of security, will encourage them to feel part of the solution, and engender good habits in their day to day activities. If the HMRC junior employee had had some education around the value of sensitive information, the trust placed in them by their customers - the British people - and the risks inherent in moving that data from a secure place to an insecure one, then maybe that breach would never have happened.

Much talk after the events above was about technological prevention and improving procedures. But human nature suggests that whatever technical or administrative control you put in place, there will be a tendency to resent the control,  to see it as a barrier to productivity and to work around it. More so if the subjects of the control - the employees with pressure to get the job done - perceive it to be too restrictive, or don't value the risk you are mitigating.

Technical and administrative controls have their place, they are a major weapon against data breaches. But a far more effective weapon is the power of human nature. Education programmes can go a long way to change staff behaviour and keep your data safe.

Why then do we spend so much money on technological solutions to human problems? DLP and Security Incident and Event Management (SIEM) are often recommended after a breach with its roots in human error. While these have their place, human element measures such as education are often more cost-effective. So why the technological focus?

Maybe it has something to do with the people doing the recommendations. Maybe the auditors, analysts and CISOs feel they have to justify their position and sizeable fee by sounding knowledgeable. Recommending staff training does not sound like expert Information Security advice. It's too simple, and not what we expect from a CISSP/CISA/whatever. So several new appliances and desktop software suites are recommended - the latest wizardry - thus the CIO feels he has received value for money from his security experts.

This needs to change. We need to value the human element in our Information systems, and recognise that it needs managing at least as expertly as the digital elements. Our people need help, encouragement and empowerment to become security advocates.

Once you've established a permanent, rolling security education programme then you might want to review your technical controls and ensure they are appropriate to the risk you are managing. Who knows, maybe you might find you can relax some controls without degrading your risk posture, and at the same time make your staff more productive. And what CIO doesn't want that?

Information Wants to be Free 2.0.

It's a refrain from the early days of computer hacking. A rallying cry of hackers, anti-censorship activists and just plain anarchists it dates back at least to the mid-80s use by Stewart Brand, while the phrase "Information wants to be free" has been used by bloggers the world over to justify the current Wikileaks phenomenon. But the phrase has a new connotation, a new white paper from Intel quotes the old hackers mantra as one of five new "Irrefutable Laws of Information Security".

Intel's use of the phrase recognises the fact that employees, associates and outside agents regularly find ways around our efforts to contain our data and many do so without malice but in order to get their job done. We should therefore recognise this behaviour and manage it, instead of trying to limit or quash it. This is genuinely refreshing stuff from a big name, and is a timely response to David Lacey's call for new standards and security models. The five "laws" in Intel's model are:

1. Information wants to be free
2. Code wants to be wrong
3. Services want to be on
4. Users want to click
5. Even a security feature can be used for harm.

The full article explains these laws and how Intel has devised new models to achieve security within them, including the "Trust Calculation" to provide an access control model flexible enough to support remote working with a variety of portable devices and locations. 

As someone who has been suggesting for a while that compliance does not equal security, and the human factor is much much bigger than most of us credit, I think this is genuinely forward-thinking stuff and I look forward to the Information Security industry's response.

Mainframe Security, PCI-DSS and other docs

Sorry, I've been busy with my other blog for a while, about System z (IBM mainframe) security, which if you missed the announcement is over here on IBM's developerworks.

I'm delighted to be able to tell Practically Secure: readers that I've written an article for respected mainframe magazine z/Journal, discussing mainframe security. While it's mostly about System z, the general concepts (including the paragraph entitled "Secure for Compliance, Don’t Comply for Security" will be of interest to all. Some of you may be familiar with the content if you've been reading me long enough.

z/Journal is here, and my article in the Dec/Jan issue can be read online in HTML format here.
For completeness, here are my earlier white papers written for Pirean.com (all rights reserved by them) covering mainframe compliance, and PCI-DSS.

InfoReck blog, great minds etc...

I'm delighted to have found this blog, written by Robb Reck, because we share a common belief that Compliance does not equal Security, and worse, that Compliance efforts can make you less secure. This post summarises his position and is essential reading for Infosec professionals and CISOs.

InfoReck» Blog Archive » Security Leads to Compliance

Amusingly we both wrote mid-year on the subject of compliance regimes hindering security efforts. I swear I had not read Robb's column before writing mine. Enjoy.

55% care about PCIDSS

41 of 74 respondents to a poll on Anton Chuvakin's Security Warrior blog put PCIDSS top of their list of concerns. Alright it was a leading question and unscientific, but I'm pleased to see such interest anyway. Maybe this reflects the looming Level 1 deadline for full compliance and regular audits. Maybe it's the fact that the PCI are now collecting fines at an alarming rate. Whatever, up to now we've seen a very slow uptake for a mandatory standard with tough penalties and this is good news. I guess the standard's arrival during a recession has caused a bit of a "wait and see" attitude in the boardroom. But this is risky. PCIDSS is not just another regulation. If you're not compliant, you're at risk of serious fraud, data loss and reputational damage.

You shouldn't comply with PCIDSS to get a tick in the box and a certificate for the lobby. You should do it to preserve your business.

The case for PCI-DSS and Ripped Abs.

I just caught up with this post (which I had squirrelled away to read later with my Google Bookmarks toolbar and just rediscovered). Some nice work here by Bob Tarzey in summing up the main requirements of PCIDSS, the advantages of getting ready and the basic implications of breach. PCI might be the kick that some firms need to re-assess security: the regularity of the audits might just make the difference. It's easy to put off spending money to counter a threat with an Annual Rate of Occurence (ARO) calculated as 0.1 (i.e. every 10 years) - human nature and available time dictate that the auditor landing on your desk every quarter wins hands down.

Check out too the comments on this post, also on silicon.com. The griping about variable approaches from the assessors is to be expected with any new standard, I think this will settle down in time. On the particular issue about voice recordings of CCV2 numbers, I would hope encryption and strong access control over the voice recordings would suffice but would welcome clarification from the PCI on this or any views from QSAs reading this.

In any case, as I have blogged before, don't make compliance with the standard your goal, make good security your goal and you will achieve compliance as a direct consequence. Or as Papa_K puts it rather nicely on that comment thread: "If you prepare for compliance audits like you prepare for a punch in the stomach to prove your abs are strong then you'll not be prepared for the sucker punch."

New IBM developerWorks blog: zSecurity

I've opened a new blog on the excellent IBM developerWorks platform called zSecurity. My readers who are not interested in System z issues will be delighted, as I will keep System z-specific content to that blog (and it might spill out into wikis later but that's another story) and stick to wider InfoSec stuff here.

zSecurity is here, please take a look and subscribe to the feed if you're interested in RACF, zSecure, Tivoli Security Software for z/OS and Linux on z and Enterprise Security with a Mainframe.

If you're already following me on Twitter as @alanjharrison then you will be happy to know that I will tweet my dW blog updates just as I tweet these Blogger ones, so nothing else to do there.

Thanks for reading, InfoSec people stay here, System z people: see you on dW! Thanks.

zNext - One Box to Rule Them All?

The hype is building for zNext, the next generation of IBM System z servers. z10 brought unprecedented power, resilience and versatility to the large server market. But the next generation - first dubbed z11 and more recently zNext - is rumoured to be a step change in architecture that some are suggesting will change the datacenter game completely.

We know some stuff already, that the processers will be down from 65nm to 45nm junctions and run around 5GHz giving up to 43000 MIPS [PDF] which represents about a 25% improvement on the z10. So far so impressive, but not earth-shattering.

But more recent rumours from Poughkeepsie have suggested something bigger is happening. The word "Hybrid" has been used in connection with POWER systems, suggesting that the new architecture will cross traditional platform boundaries. And one source told me that Teradata will be in the frame.

A System z that also runs native AIX and Teradata right out of the box? Wouldn't that be groundbreaking?

IBM have now announced the reveal will be in a July 22 webcast to partners. If you can't make it, come back soon, I'll be blogging about it here shortly after. Follow me on Twitter, LinkedIn or by RSS feed to get the news first. Might this be the game-changer, the killer blow to IBM's high-end server opposition, and then some?

Is there a Mainframe Skills Shortage?

I like Joe Clabby. He tells it like it is. He has responded robustly a number of times now to Gartner advice to move off the mainframe to more "modern platforms". His latest such article is here.

However I think the truth lies between Gartner's doom and gloom predictions and Clabby's upbeat "you've never had it so good" optimism. Don't be under any illusion, decades of in depth knowledge of mainframe systems is going to leave your organisation over the next few years. But where Gartner gets it wrong is their insistence that the solution lies in migrating off the mainframe. They have used that phrase "more modern platfom" many times in recent years and this is starting to look like staggering ignorance of what IBM have been doing with System z for ten years.

There's no need to move off System z for modernity. IBM have brought modernity to System z. You want management GUIs? Check out the Tivoli automation range. You want a visual developer platform? Rational Developer for z (RDz). You want to run Java, C and C++? No problem. You want to consolidate your racks and racks of servers? Virtualise them? z/VM is the worlds most mature hypervisor, add SLES or RedHat Linux for up to 1500 servers in a 30kW box 10 feet square.

But I do think now is the time to modernise your mainframe. To streamline and automate the maintenance and management of the infrastructure. The product set has never been richer and I recommend you take a look. The greybeards will go soon, and while there are a new generation of System z afficionados leaving college as we speak, don't make them suffer needlessly. Enable them to be productive and creative. Simplify, streamline and automate with IBM Software.

Secure for Compliance, don't Comply for Security.

It's been all about compliance for the last few years. Wave after wave of legislation has left us reeling, it seems not a week goes by without a recertification, attestation or visit from the auditors. Maybe we're passing our audits, maybe our auditors are giving us glowing reports as our procedures and the evidence of their being followed ticks all the boxes.

But we still get hit by a security incident. Maybe the theft of thousands of customer PINs has been traced to our software support team where a little known privilege has been exploited. Or the recent DoS attack on our web servers was routed via a previously unknown and unpatched print server. Or a rogue trader in our dealing room has been escalating his privileges to allow himself to both raise and authorise payments to his holiday fund.

How did this happen if we're compliant? Perhaps we focussed too narrowly on the specific directions in each piece of legislation, performing a box-ticking exercise on them all (which in practice often means lots and lots of new, labour-intensive processes such as user recertification, dual authority, two-factor authentication, enhanced monitoring, reporting and change control).

Ironically, it is all of this focus on new processes and procedures - implemented with the right intentions: to enforce security policy - that has made us less secure. Because now our technical staff - the experts in the hardware, OS, infrastructure and applications who were previously doing their best to keep ahead of new threats - are now hamstrung with attestations, visits from auditors and recertifying user access rights.

What happened?

Well perhaps the new compliance framework was implemented as a stand-alone instrument, a panacea rather than being used to inform and enhance existing standards and processes. Perhaps not enough thought was given to the extra work involved, or in developing systems and software to enable the new processes, ensuring they have minimal impact on productivity. Perhaps we didn't recognise the things we were already doing that were contributing to compliance, and building on these. Perhaps we saw Compliance as a "New Thing" and sought to implement it as such. In short, we sought compliance for its own sake, and thought that compliance would bring us security. And perhaps we hastened to become compliant with a single piece of legislation such as SOX but didn't build a framework scalable or flexible enough to absorb further controls and threats. And we relied on auditors with little technical knowledge to tell us when we had got it wrong, and their technology-agnostic box-ticking failed us.

We need a new approach to compliance. It's the old approach but better. We need to go back to basics and take a proper technical approach to security. We need to identify and tackle all existing threats against all of our components whether hardware, OS, infrastructure, application or web service(which incidentally needs a sound approach to configuration and change management that should include automated discovery) and a means of identifying and tackling new and emerging threats. We need to let our technical guys have greater input to the process and encourage and enable them to raise security issues and resolve them. And we need to bring back the technical audits.

We need to revisit our Security Policy, ensure it supports all of our security and compliance goals, and then use this to inform lower level documents including standards, baselines, guidelines and procedures so they all hang together. Then we need to implement rigorously, allowing our technical experts to decide what controls are needed to achieve each particular policy objective. And we need to remember to lock in compliance, with as many automated detective and corrective controls as we can - thus achieving Continuous Controls Management at the same time.

To give you a flavour of what I'm talking about, consider RACF. A typical (abriged) SOX control might require that "privileged users are kept to a minimum" and another might say "privileged user activity should be reviewed". Typically, well-known RACF privileges such as SPECIAL would be well covered by this control. The control objective, control details, processes and procedures adopted to implement this control would be comprehensive for SPECIAL users. Evidence is collected and preserved showing that SPECIAL users are well controlled.

Enacting a self-fulfilling prophesy then, SOX auditors come in and report compliance, but only because we are doing what we said we would do and protect SPECIAL users. The SOX auditor will not verify that controlling SPECIAL users is sufficient to achieve the SOX control objective of curbing "privileged users".

In our practical example, our Software Support programmer exploits a lesser-known privilege, say SURROGAT authority to a second SPECIAL user, UID(0) or UPDATE authority to a privileged user's EXEC or HOME library where he plants code (somewhat like a Trojan attack on z). These are all esoteric privileges which generally are not well controlled in a System z environment. But they are privileges nonetheless.

Staying with System z for a moment, we can avoid this situation if we let the RACF Admins and z/OS Sysprogs dictate the controls required. The true vulnerabilities of the system should be tackled, the real threats deterred and the actual risks reduced.

Then we provide evidence upwards, with our hierarchy of documents and a decent control framework we can determine which technical controls contribute to which higher control objectives, and therefore we can demonstrate compliance with each standard, baseline or policy as necessary. If we do it right we can secure once, comply with many.

In short, top-down imposed compliance has not made us more secure. Only a bottom-up approach - informed by the policy but driven by the technology - will work.

We need to Secure for Compliance, not Comply for Security.

RACF Permissions in ITIM

Available now on Pirean.com is some new System z content, written by me about the services Pirean provides for the mainframe platform. I'm passionate about the platform, System z is truly the "ideal server" and provides leadership resilience, availability and security, and a host of other benefits ably described in this blog post from Jonathan Adams on the excellent MainframeZone.

Also on the Pirean System z page you will see a link to a PDF you can download describing the new adapter for Tivoli Identity Manager Pirean has created. I'm very proud of my role in this, and grateful to Stephen Swann and others for their TDI and TIM expertise without which the product would not have seen the light of day.

System z roadshow in Atlanta is Go!

I've made it to Atlanta. See you tomorrow for Mission Critical Workloads on z? Full details and registration available here, and see earlier blog post for sneak preview. Abstract from the agenda:
"In this seminar you'll see how Tivoli, StreamFoundry, and Pirean are delivering highly available Linux on System z platforms that support mission critical workloads and how you can develop your own cost effective solution". Looking forward to it.

Find out even more reasons to attend Pulse Comes to You, 27th May

Attend Pulse Comes to You and find how IBM is making major changes to the IT landscape — and how you can be a part of that. At the Grange Hotel, St Paul’s in the heart of London on the 27th May, 2010

And just announced—two-time Olympic gold medalist and co-star of the BBC series On Thin Ice, James Cracknell, will speak at PCTY UK 2010! Don't miss what promises to be an entertaining and inspirational presentation by one of Britain's most successful athletes.

Register via sponsors Pirean here and win an iPad!