Risk Management with Stuart King and Duncan Hart

I was re-reading the VISA CISP data security standards documentation and reminding myself firstly, of what an enjoyable read this is, and secondly of some of the recent new clauses put in to entertain us. Clause 6.6 (on page 8 of the document) states that application layer firewalls are "considered best practice until June 30, 2008, after which it becomes a requirement."

Once I returned from buying shares in various application firewall vendors I re-thought the merits of this clause and whether or not it is really something that should be a requirement.

I know from experience that application firewalls have their place. For example, take an instance where you have a vulnerable web product and need a quick fix for multiple problems. Sure, the underlying problems still remain but in the meantime you have defences in place that work to mitigate the immediate risks. So the device becomes the proverbial rug that the dust gets swept under. However, CISP are requiring implementation of a device regardless of the risk status which means that you have to find the budget, find a person to perform the administration and management of a device that needs to be updated with new rulesets each time you perform an application change, and then plan upgrades and replacements to this device throughout the entire lifecycle of your product.

Surely if you have applied all of the previous mandatory clauses in the CISP documentation then you will have, in my opinion, mitigated most of the product related risks to a pretty substantial degree, demonstrated due-diligence and have a secure product. I don't believe that the addition of the firewall buys much extra risk mitigation in this instance.

As you will learn, I'm a believer in process before technology and not trying to solve problems before you understand their causes - and I think that this requirement is overkill. What do you think?

Some news in SC Magazine caught my eye:

Businesses are failing to boost productivity by preventing wireless internet access to visitors due to security concerns, new research shows.

This is just the sort of crass reporting that really gets my goat. Firstly, the organisation performing the research in this instance is a WiFi provider so it's not exactly a neutral viewpoint they are coming from. Secondly the quoted Managing Director of Guestbridge is one of their customers and thirdly, the article says that they sought the views of IT workers - well, I'm sorry to say this but just about everyone I know in IT will say that we need to have the fastest, newest, shiniest, technology without a thought for whether it's actually of any use or not. Me included (and support - if you are reading this, please can I have one of those new shiney things that goes beep, before it becomes obselete?).

Now I can tell you that the reason there is no wireless in Corporate Towers (the office I'm based in) is absolutely none of those listed in the article - and while 23% of the HR department polled suggested that they suspect it might be useful if a guest turns up with a laptop computer expecting unlimited Internet access at our expense, the corporate management decided that we'll make them endure the horrid incoveniance of having to plug in a nasty cable. And do you know what: I'm not sure that our productivity has dropped by a single percent as a result. But the productivity of our IT support certainly would if they have to spend all their time running after VIP guests who want to check their Hotmail accounts from the comfort of the reception area and wonder why they are viewing the Intranet system of the company next door.

I'm astute enough to know that having wireless can be conveniant for visitors. We have a number of business units that do have wireless and offer guest access. In fact, as an organisation we've done a good deal of research into wireless and associated security - providing campus wide solutions and being early adopters of new technology. But does it increase productivity? Perhaps the missing 12% from The Cloud's research might be able to tell us (check the numbers).

I sat in a presentation recently where the words "regulatory compliance" were used no less than 27 times across 45 PowerPoint slides. I've even found myself using the term in meetings more times than should be legally allowed, and rarely a day passes where "regulatory compliance" is not written within an email or seen in a document or uttered in the men's room.

Similarly, never have so many consultants been able to rub their hands together in glee as we are bombarded by an ever increasing need for RC (as I shall now refer to it), and the requirement for us to be audited, checked, tested, and examined most intimately all in the name of proving compliance. Even within the business we are subjecting ourselves to more audits all in the name of RC. SOX, PCI, HIPPA, GLBA...the list of acronymns is growing at a rate where more of us are demonstrating our knowledge of RC by virtue of the number of different acronyms we can drop into casual conversation. Those of us with the greatest knowledge can even use RC related humour ("how many SOX consultants does it take to change a lightbulb? " etc etc).

David Lacy mentions in his latest blog that our ability to safeguard data depends upon "sensible application of well-established security technologies." I am in complete agreement and this remark also relates to our efforts to maintain regulatory compliance: as I discussed in my blog yesterday.

At the present time I'm working on a method of categorising web products according to their risk profile: the profile is based upon strategic importance, revenue and, of course, the regulatory aspects. By doing this work, we can ensure that a security policy is applied that relates to the risk posed by the product. Of course, just having a policy doesn't provide assurance. That assurance comes through having good development processes throughout the life-cycle, and having thorough risk assessment, review, and risk mitigation processes. It's all part of having a sound Risk Management Plan (RMP). The RMP is the foundation of my work and over the next year I'll be providing some insight into how successful or otherwise this is.

PCI compliance is important, and not just for the sake of protecting credit card data. It's a simple security standard that we should all be able to easily achieve using existing tools, techniques and technologies. And if your arguement is that you can't afford to do it, then I'm not going to be buying anything through your online services.

I've commented on this subject before - and no doubt I'll be doing so again - because being compliant with the PCI standard demonstrates more than just an ability to handle online payments, it's a show of "superior security" that will reflect in your overall risk status.

There's a great blog devoted to PCI here. I recommend it.

http://datasecurity.wordpress.com/

What exactly does "compliance" mean? If I'm reviewing a product and conclude that it is compliant against some particular policy or regulation then what that really means is that it is compliant at that particular moment in time. This is a point well made on the PCI blog and it's something that businesses should reflect on regardless of whether they are aiming for compliance with regulation or simply wanting to comply with an internal policy. The reason, obviously I hope, is that web products in particular present a moving target. A component deemed secure today might be completely insecure tomorrow when the next change is implemented .

It's therefore important that change control includes processes for ensuring continual compliance. Changes should be reviewed for security impact, and their risk assessed. It sounds easy doesn't it? But that's assuming that there are suitably security-aware people available and also that the potential impact of a change can really be known. For instance, a change request to open a new port on a firewall can be easily assessed, however, a request to deploy a new customer-facing enhancement to a web product needs a diffierent approach. Having security baked into the SDLC is an obvious good place to begin however, playing devil's advocat here, let's say it's a change that needs to be implemented fast to resolve an earlier customer-facing (non-security) issue. There is going to be a good deal of pressure to deploy: the business needs to maximise revenue and get the product working fast, the development group is going to be under maximum pressure to deliver fast and the developer will be focusing on the functionaility rather than the security. Can a compliant product still be delivered under those circumstances?

The answer, in my opinion, is probably no. The most likely result will be after-the-event bug fixing and a period of non-compliance. It's an expensive way to do things and while we all know it's cheaper to address problems prior to deployment the real-world is often not as we would really like it to be.

So, faced with a need to be compliant on the one hand but a star product requiring a quick but complex change on the other what can we do to ensure we don't attract the ire of the auditors? PCI clause 6.6 might provide some of the solution. Namely "installing an application layer firewall in front of application." Yes, I know that I've previously stomped on this clause and bemoaned the fact that it's not problem solving from a development perspective but from a business perspective it's a different matter because while the bugs still sit on the server, at least the device is protecting against them being exploited.

It's not a perfect solution and I'd prefer to see more review and testing during the life-cycle but as I stated earlier, the reality is frequently less than perfect and our role at the end of the day is to adequately mitigate risk. In my mind that means ensuring that the business can still function, protects assets, and meets it's security and compliance obligations in the easiest, most cost-effective manner.

So, going back to change control, which is where we came in for this blog, we need to work on improving processes to ensure that security impacts are reviewed but we also need to be aware that this cannot always be assured. When that is the case there are alternative solutions that help us maintain compliance. Make sense?

One last word, and sticking on a PCI theme I wonder if TJ Maxx - the latest company to suffer a breach of credit card data were PCI compliant. There's a clause on the TJ Maxx web site privacy policy which states: "Unfortunately, no collection or transmission of information over the Internet can be guaranteed to be 100% secure, and therefore, we cannot ensure or warrant the security of any such information." That, in my opinion, is a crass clause that has no regard for their customers. Instead of making such blunt and utterly pointless statements surely it would be better to state that they are doing all they can to mitigate risk. However, current events show that they obviously were not and I wonder how their own change control measures up. Anyway, another example of a business making the headlines for the wrong reasons and it should serve as a reminder that compromises are still very much a danger if we leave the door open. Amen!

Some excellent commentary from Mark Curphey on the subject of the PCI DSS over on his blog at http://securitybuddha.com/.

The other element of the PCI DSS that is of concern is the Audit Procedures and Reporting document designed to be used as the principle guidance for PCI certified auditors. Picking up on Mark's point about item 1.1.9 and the requirement for configuration standards for routers, the audit guide is just as ambigious in only instructing auditors to "Verify that firewall configuration standards include both firewalls and routers." That's it!

Another audit clause that really gripes me is this one:

6.5.b For any web-based application, inquire (sk - shouldn't that be enquire?) of a sample of (insert sample size) web developers and obtain evidence that they are knowledgeable in secure coding techniques

It's almost as vague as the audit guide around clause 6.5.10 which expects the auditor to check there is no "insecure configuration management." What does that mean? You can have poorly managed configuration management or incorrect configurations resulting from errors and lack of knowledge but I don't know if that is the same thing as insecure configuration management. Perhaps they are referring to insecurities of the person performing the management. I imagine they are on the lookout for some network admin asking himself "am I any good at this whole configuration lark?".....

What is boils down to is that the audit guide is just as ambigious as the standard itself.

One of the interesting points somebody made earlier on this week was about the difficulty individuals face in this country, if they feel so inclined, to claim damages against an organisation under the terms of the data protection act. The point was explained as follows:

Individuals can sue under the DPA BUT
a) The data subject must prove damage AND
b) The data processor can defend this lawsuit on the basis that they tried to comply with the rules AND
c) How much money will they win anyway?

There are many sources of reference warning organisations of the punitive fines that could be levied against them in the event of a breach of personal data. However, unlike in America where your personal feelings of being violated in the event of your data being stolen could result in the award of a decent retirement fund; here in the UK, the judge is more likely to tell the plaintive to grow up, stop whining and provide a DNA sample on the way out. In fact, when Liverpool city council were fined recently for the henious act of failing to comply with an information notice from the Information Commissioner's Office (another government agency), do you know how much they had to pay? Have a guess. £300. Our American friends wouldn't even have woken up, let alone gotten out of bed for that one. So, what chance a private prosecution for a data breach?

The question is, does that mean we don't need to be so concerned? I'm ashamed to have even asked the question, because if you don't know the answer then I hope none of my data is on any of your systems. If we're charged with the responsibility of looking after personal data (as defined by the DPA) then we have a responsbility to do our utmost to be reliable guardians regardless of whether or not the chap in the wig is going to make us dig into our pockets if it's compromised.

There's our own reputation to think of too. Data breaches cost more than just legislative penalties - they hit share prices and they hit investor confidence. See my earlier blog entry here for more information about how much.

The point I want to make applies also to PCI, SOX, HIPAA, and any other of the multitude acronyms that we have to contend with these days. Why are we doing the work for them? To be compliant you will reply. Wrong answer - go to the bottom of the class. The correct answer is because we desire to mitigate risk and implement a decent set of controls and above all do the right thing. If we were already doing that then the legislators wouldn't need to bother with us, and could go and pick on somebody else, and PCI would stand for something else completely.

So, the message is to continue striving to achieve the standards required of regulatory compliance but do it because you want to achieve a decent level of maturity in terms of information security rather than just to put the ticks in the boxes.

I was pondering on whether or not to go to the PCI DSS conference. I've decided not to go because, frankly, I think the whole thing is now becoming a big waste of air. So many people are now making cash out of this: consultants consulting on how to achieve compliance, the banks raking in the fines for non-compliance, the vendors selling their technical compliance solutions and now SC magazine with their "book before 4 October and save £100" conference on the subject. In the meantime becoming compliant doesn't actually mean a thing. I know this because I've drilled big holes through the security of so-called compliant companies who are still able to tick every box on the PCI SAQ questionnaire and pass a network scan.

I'm also bored with people who tell me that PCI compliance has to be our top priority. This is simply not true. Securing data properly and protecting our company assets is the priority - if we do that right then we're PCI compliant by default. The same point is made on the PCI Answers blog: PCI isn’t an automatic validation of an organization’s security posture. In-fact, ignoring the intention behind PCI can turn it into a detriment. Compliance is not security.

I well understand that if I can go to my management and show them the quick wins I've achieved against the PCI DSS that it makes me look good. Oh look sir, this month we had our fax machines secured and so can tick all the boxes on the PCI assessment. Have we reduced risk to the business? Not a jot. Your PCI network scan came up clean. Are you safe? Sure, in the same way as having paper walls soaked in petrol can be certified as not being on fire.

If PCI Compliance were a ready meal, it would be a very bland one. The point I'm making is that it's nothing to get excited about. The best example I can point to is the recent TJX case. According to an article published a couple of days ago, the attack took advantage of poorly implemented wireless encryption.

The wireless LANs were secured only by Wired Equivalent Privacy (WEP), a technology that has been known to be vulnerable for more than a year...the report concludes that TJX did not take sufficient steps to secure or dispose of the sensitive data. The company's upgrade from WEP to WPA took too long, and sufficient encryption was not put in place, it says.

2.1.1 Verify the following regarding vendor default setting for wireless environments:
• WEP keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions

Clear enough?

I really enjoyed reading the interview with Adrian Asher in the latest edition of SC Magazine. Adrian is global head of security for Betfair: a company with more than a million registered customers processing as many transactions each day as the London Stock Exchange. I think that's a security challenge most of us would like to get our teeth into.

Adrian mentions an impending ISO27001 audit and it started me off wondering if perhaps I'm guilty of neglecting this important standard. For those of you who are not familiar, ISO 27001 is regarded as the de-facto standard for establishing, maintaining, and improving an Information Security Management System (ISMS). Achieving certification against the standard is evidence of an organisation proving that they take information security seriously

I'm certainly not unfamiliar with the standard, having documented a gap analysis for my organisation a couple of years ago. What I wasn't able to do is build a convincing business case for proceeding with a project to achieve certification. At the time, being ISO27001 certified wasn't viewed as adding value to an organisation that already had in place many mature risk and information security management processes.

I now find myself wondering if this wasn't short-sighted. I've been re-reading the standard and also reading about how others have gone about their own program of certification and the benefits they achieved from it. The aforementioned Betfair, for instance, are reported as now being able to "demonstrate its commitment to the integrity of its information systems, assuring its customers of optimum security for personal details." The CEO of CHKS, a medical consultancy organisation, stated that "ISO 27001 has provided a rigorous standards framework against which we can be objectively measured. We are delighted to have achieved this internationally-recognised certification especially as the role of IT in corporate governance continues to expand". Monitor Media, a solutions development organisation who also achieved certification state "Though we've always taken the issues of information security extremely seriously, it was nevertheless appropriate to invite an external audit from a tough and respected body like the BSI."

There are many more examples I could quote from. In short, the message is that becoming ISO27001 certified is an indication, not only of taking security seriously, but also of following a good process of governance that can be recognised within the business and by customers too. Win win.

There are many other positive reinforcements of the message that certification is a good thing such as the blog posting here from Brian Honan. In fact there appear to be few, if any, down-sides other than managing ones resources sufficiently and making the time to commence a certification project.

So, I'll be thinking about ISO27001 over the coming months and looking for the opportunity within my own organisation. I'll let you know how it goes.

I wanted to take an opposing view to David Lacey's blog on California's veto of AB779 - the bill to make a version of the PCI standard into State law. David's view is that "in the absence of tough legislation, few organisations pay enough attention to the protection of customer data." I agree with Arnie's view that "the industry is better equipped than lawmakers to evaluate the need for higher standards." In fact this is already happening in the form of the National Retail Federation who earlier this month sent a letter to the PCI Security Standards Council requesting "changes in how the credit card industry requires merchants to store credit card data. " You can read it online here.

I also think I'm not far wrong in saying that in the case of PCI, many businesses have been taking very seriously the threat of financial penalties that the banks are starting to impose on merchants who fall out of compliance (Visa alone imposed US$4.6million worth of fines during 2006). That's before we get to the fear of the reputational hit that comes with a credit card data compromise - legislation or not. Government legislation has not been needed.

I'm not disagreeing that tough legislation can work to focus efforts on security, just that I'm not convinced it's actually necessary. I was giving a presentation recently to a business that is completely focused on ensuring that it protects data not because of legislation (although compliance with various bills and acts was obviously a driving factor) but because it wants to safeguard customer interests, and protect reputation and revenue. Get those efforts right and the business is likely to be compliant anyway.

What do you think?

Some new mandates from Visa released last week. Read the full bulletin here: http://www.computerworld.com/pdfs/Payment_Application%20Security_Mandates_9044159.pdf. Here's a summary

David Lacey makes the important point that writing secure software is "not just about cutting secure code or developing better testing tools. We need to get things right much earlier in the development process." It's a subject I've been harping on about for some time, with many references to excellent resources such as OWASP, and great leaders on the subject such as Mark Curphey.

Over the last few years I've heard many solutions proposed to fix the problem of insecure software, ranging from sacking the developers to improving the software development lifecycle so that security requirements are stated from outset and followed through into production and beyond. The evidence is that none of it works. OK, the folk at Microsoft, for example, will say that security is now embedded in their culture, and they've certainly generated a nice new stream of revenue for themselves out of all the books, tools and journals on the subject. But they are still releasing security patches with a frequency and schedule that the I wish the rail company I use each day could achieve with their trains. And other vendors are coming up with clangers at an alarming rate. For example, this latest one from leading CMS vendor RedDot. An SQL Injection vulnerability in an enterprise level CMS system - what were they playing at with their quality control?!

So, here's the thing. We can't write secure code. It's true. Can you show me any decent commercial, consumer focused product (that people actually want to use - not just techies who haven't seen daylight in 12 years and live on a diet of digestive biscuits) that is secure from the off as soon as it's exposed to the Internet and where 12 months later it hasn't required a patch of some sort? Systems are simply too complicated with too many lines of code for anyone to expect that they can be released without containing bugs and security holes. That doesn't mean that we shouldn't try, it just means that we should take a different approach. That approach, in my opinion, is to take a leaf out of the new edition of the PCI standards and stick a ruddy great application firewall in front of everything. That doesn't make the code secure, it's a sticking plaster over a wound. But - to continue the analogy - a plaster stops the bleeding, prevents germs getting in, and while it's not a cure, it's good enough.

I'm not knocking OWASP et al. It's the first resource I recommend developers go to and will remain so. Just that the business expects more functionality, cheaper costs, more complexity, better performance, and a more rapid deployment for its products. Chucking in security with all that lot is like rubbing your belly and patting your head at the same time, while riding a motorbike. So, let's make it easy on ourselves. Application firewalls!

Known as "that Moron in the White House" by my American father-in-law, President Bush yesterday signed into law a couple of things that you might have missed.

H.R. 2356, which encourages the display of the flag of the United States on Father's Day;

S.J.Res. 17, which encourages the United States to initiate international discussions with other Arctic nations to negotiate an agreement for managing migratory and transboundary fish stocks in the Arctic Ocean.

H.R. 4008, the "Credit and Debit Card Receipt Clarification Act of 2007," which specifies that certain entities that printed an expiration date on certain credit and debit card receipts were not in willful noncompliance with the Fair Credit Reporting Act;

Were you aware of that last one? It relates to FACTA - the Fair Credit Reporting Act - which, amongst other things states:

Except as otherwise provided in this subsection, no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction.

Any American consumer who purchases goods or services from an American based company has a right to take legal action if the receipt from a credit card transaction shows either more than the last 5 digits of the credit card number or the card expiry date. And there are quite significant fines at stake as well. According to this document, Costco, California Pizza Kitchen, FedEx Kinko's, IKEA, Wendy's, TGI Friday's, T.J. Maxx, and Radisson Hotels (among others) are all defending against FACTA class action lawsuits.

According to the receipts I'm presently carrying around with me Starbucks and Sheraton Hotels should be very wary too! It's unfortunately all too true and if you're doing business in America then you need to be aware of this legislation and check whether or not your business is compliant. 

I've been following an interesting Q&A thread on LinkedIn where the question is asked "Should business messages be allowed to flow through personal/webmail services?"

What's interesting to note is the difference in opinion between the more technical network security analyst types and those more business orientated individuals.

Security & Systems Engineer: This should not be allowed. Security is tough enough without introducing additional systems that are not under your control

Sr Systems Architect: Business messages should not be allowed to flow through personal services, just as employees should not be doing work on the home computers.

Network and Data Security Architect: Absolutely not. It's unprofessional.

Information Security Specialist: This is a business decision not one for IS engineers

Principal Consultant: while many security researchers and practitioners would be quick to shoot down the suggestion of personal webmail, that's oversimplifying the situation

Chief Information Security Officer: The business owns the data, so they measure the risk and define the acceptable use for that information

This comes back to the point I made a few days ago about not allowing the IT department to set policies. Decisions such as this must come from the business and I wholly agree with the response quoted above from the CISO. If the business decides that it needs to use webmail services for whatever reason then it's up to us to ensure that the risks in doing so are adequately mitigated, communicated, agreed etc. Of course, I might want to recommend a different service from the one being proposed and I would hope that my views on risk would be taken into account (and don't forget to review the terms and conditions too - you want to make sure that you still own your own documentation!).

In this particular question of webmail, there is a much bigger picture to take into account too. "In the cloud" services (PaaS, SaaS) such as Google Apps, web-based email, SFDC and so on will, in my opinion, one day very soon be just as normal in the workplace as Microsoft Word and Exchange-based email are today. We need to adjust our thinking accordingly.

The Cabinet Office recently commissioned Nick Coleman, an Independent reviewer of Information Assurance for the UK government , to report back on how well the Government is doing when it comes to protecting and handling information.

The result of that review, The Coleman Report, can be downloaded here: Coleman Report.pdf.

It's a succinct document, first describing the transformation to electronic-based services (for example, in one week the NHS sends 1.4 million prescriptions electronically) across the public sector, and secondly highlighting the main features of the changing environment. The two stand-out items being the rapid pace of technological change, and information sharing on an unprecedented scale.

The section on "Findings from the review: how well is government doing" does not make for particularly positive reading. For example, when talking about accountability Nick states that

"no role exists to provide Independent Oversight that the appropriate Governance;
Information Risk Management; Policy and Operations; and Monitoring and Controls around Information Assurance are in place across departments and agencies."

On risk management, we get also get a far from positive report;

"Risk assessment is patchy leaving many without a clear understanding of the risks they are facing or exposing their stakeholders to."

The list of recommendations makes for equally gloomy reading. And here's why. We've been talking for years, even decades, about the need for strong information security governance, accountability, and setting minimum standards. It's nothing new. But here we are heading towards the end of the first decade of the 21st century and a report about and for the Government - the highest authority in the land - is highlighting a need to  "Define minimum standards that (public sector) departments sign up to"

Good grief. What on earth have they been up to all these years? If there were a book entitled "Information Security for dummies" then that would be on page 1. It shows just how far behind the public sector is and makes for good explanation as to why it is subjected to so many data breach incidents.  

There is a follow-up ministerial statement here. The range of measures being described is sensible enough but even in a modest size commercial organisation such measures don't get implemented overnight. It's going to be a mammoth task in my opinion.

"The Government is determined to take the necessary steps to improve data security."

I don't doubt it.