NoticeBored blog

An article about responsible Twittering hints at a broader concern for all social media, and in fact all forms of communication between the office and the outside world. Examples in the article include people falsely claiming to represent their employers and disclosing sensitive information via Twitter, plus Twitter being used to direct potential victims to infectious sites hosting malware. People have done the same kinds of things for years using email, telephone, blogs, bulletin boards, IM, VoIP and so on - even letters in the post: the incidents are pretty similar though the communications media vary.

This obviously raises questions about how to reduce the risks without unduly interfering with legitimate business communications. Technical controls offer limited assistance e.g. blocking IM will block legitimate IM activities, and determined users can sometimes find ways around such blocks anyway. Automatically appended email disclaimers have dubious legal validity, particularly those that are written or modified by amateurs. Policies and procedures can help but only if employees are made aware of, accept and comply with them, which requires awareness activities (such as this month's NoticeBored module) and compliance activities (such as management oversight - basically taking an interest in what staff are doing at their desks).

Risk avoidance is arguably the most effective control, in other words discouraging or preventing unnecessary office communications outside the organization. However this is likely to have an adverse impact on legitimate business activities, and hence costs.

Since the controls are evidently not perfect, wise organizations make contingency arrangements in preparation for situations when the controls fail and incidents occur. Examples:

• Incident notification and specific response procedures covering these kinds of incident;
• Response procedures include 'damage limitation' using legal actions (e.g. those disclaimers and Non Disclosure Agreeand Public Relations (e.g. stock press releases ready to issue);
• "Learning the lessons" which means using incidents (particularly those suffered by the organization but also its peers and others in the public domain) as case studies and training materials;
• Disciplinary procedures taking account of incidents of this nature, typically using examples.

[Scary postscript: the Pentagon thinks there is value in 'instant comms', if only soldiers can be persuaded not to disclose little things such as battle plans ...] [Or is this just a crude attempt by the US to encourage foreign militia to permit their soldier to use Twitter ?]

Labels: Awareness, Email, Malware, Office, Risk

In "A cautionary tale about nuclear change management" ComputerWorld blogger Scott McPerson discusses a few security incidents that have been linked to SCADA systems, picking out two causes: poor change management and problems with the IT architectures. If only things were so simple in Real Life.

According to Scott, the change management problem can be solved by adequate pre-release testing of patches. Mmm. OK, well let's assume a SCADA-using organization has the resources to invest in an IT test jig comprehensive enough to model the live SCADA/ICS systems, complete with real-time data feed simulators and control panels, or at least a sufficient part of the complete live system to allow representative and realistic testing. Presumably they could test the patches and software upgrades thoroughly enough to reduce the possibility of unintended consequences, but how far can or indeed should they go? Anyone who has actually tried to do exhaustive software testing, even in a very simple laboratory setting, knows that it is literally impossible to test everything in practice. With the best will in the world, the fanciest test jig that money can buy and the most competent, skilled and diligent professional testers on the job, there is always a residual risk at the declared end of testing. In real life, the end of testing is almost always declared by management well before the testers are truly happy, not least because the issues and risks that the planned software changes are supposed to fix inevitably persist at least until the fix is applied, so there are clearly competing pressures. Damned if we do, damned if we don't.

OK, I'm certainly not arguing that pre-release software testing is a waste of time on SCADA or any other IT systems, far from it. But the reality is that no matter how much testing and fixing is done, the eventual decision to implement implicitly if not explicitly accepts the residual risk. In my experience, the operational, safety and commercial risks associated with system failures on SCADA systems are so significant that the opposite situation is more of a problem, namely that SCADA systems are not patched at all, or at least not promptly, due to the extreme risk aversion. Legacy systems are the norm not the exception in SCADA/ICS-land. In the case of safety-relevant and certified systems, plus the highly specialized bespoke systems typical of controllers for complex machinery (such as, oh er, a nuclear power station), the inertia problem is even worse.

Scott's second point about IT architectural issues also seems rather glib to me. "The fact that some utilities -- including nuclear utilities -- are stupid enough to attach the servers that control and manage SCADA systems to the same Internet that runs porn and Nigerian scams and MySpace is ludicrous. It is also dangerous." That statement seriously denegrates the highly competent IT and business managers in the utilities, manufacturing and engineering companies where I have worked. Such people are far from stupid. As I said already, they are highly risk averse and do not take such decisions lightly. But again there are competing priorities. The Internet is a convenient, cheap way to access SCADA/ICS systems, networks, devices etc. for remote diagnostics and support purposes, for example, and often glues together critical business processes throughout the supply chain. Connecting the SCADA/ICS network to any other network (even the internal corporate LAN) is clearly fraught with danger so security is always a concern.

The main beef I have with you, Scott, is that you have over-simplified the problems and provided trivial solutions, as if simply saying these things will make a difference. Calling the people who are actually dealing with the risks "stupid" is hardly going to make friends and influence people.

Labels: Change, Risk, SCADA

Our latest product is a brand new security awareness module on SCADA, ICS, DCS and related acronyms - essentially industrial process control systems. I suspect few employees outside of IT will have heard of SCADA and hardly any will have considered the security requirements associated with keeping the lights on, both literally (SCADA systems are heavily used by the electricity generators and grid) and figuratively (modern factories are packed with all manner of computerized industrial machinery). For those who work not in manufacturing industry but in ordinary offices, we point out that elevators and other facilities are typically managed by a Building Management System, itself a form of SCADA. For those who don't even work in an office, the Engine Management System in their car is another example.

In addition to the potential for unplanned production outages and disruption to critical infrastructures, the health and safety plus environmental protection aspects make SCADA security impacts potentially horrific. Simply being obscure is no defence against some hackers and, potentially, their terrorist masters. Governments and managers at major utilities are worried about SCADA security risks, so all in all this is an important awareness topic.

Labels: Awareness, Risk, SCADA

The drip-feed of news about the Terry Childs case continues. [Quick recap: Childs held the City Government of San Francisco to ransom by refusing to divulge the city's network admin passwords that were under his sole control.] The Washington Post tells us:

"Childs compromised more than 1,100 devices and created unauthorized network doorways, allowing him unfettered and undetectable access. He collected pages of user names and passwords, including his supervisor's, to use their network log-ons. And he downloaded thousands of gigabytes of city data -- possibly privileged information, such as police reports and e-mails -- to a personal encrypted storage device. Experts still aren't sure what data the device contains."

'Thousands of gigabytes'? That's an impressive capacity for a personal storage device.
The Post also says Childs had a criminal record:

"Childs, as it turns out, carried a list of convictions, including aggravated burglary, aggravated robbery and theft, according to court documents. He also served four years in the Kansas state prison. Childs kept this from his employment application, court documents note. Vinson said San Francisco will probably expand its employee background checks to cross state lines."

Good idea!
Still, I agree with the thrust of the article that SF management's failings extend well beyond checking Childs' references. Childs was a privileged insider placed in a position of great responsibility and trust by management. It appears that management recognized the risk but failed to address it adequately. Dawn Capelli's comments about the insider threat are very apt. I'd call this a governance failure.

September update: San Francisco city's Department of Telecommunications and Information Services (DTIS) has spent just under $200k already, investigating what Childs has done to the network and hunting for a terminal server providing him a back-door.  The full cost is estimated to be around $1m.

Labels: Authentication, Confidentiality, Governance, Network, Risk, Trust

We've just released our latest security awareness module on "information security risk management". The title is deliberately a bit ambiguous - in fact it cover mostly risk management in an information security context, plus a bit of information security management and a sprinkling of IT operations for good measure.

Identifying and managing information security risks is of course a key objective for information security managers. The module dispenses sage advice to managers and IT professionals on exactly what is involved in the infosec risk management process. For general employees, we emphasize the "What's in it for me?" aspect by drawing parallels between managing infosec risks at home and at work.

Whereas the PDF newsletter is free, you'll need to subscribe to NoticeBored to see the whole module in all its glory, and receive another one each month. We work this way to encourage customers to deliver rolling/continuous awareness programs. It seems to us a month is long enough to put across the essentials of any information security topic (potentially in more depth than any other awareness program we know of), yet short enough to avoid everyone getting totally bored by the same old same old. Next month we'll move on to a new topic (information security governance), hopefully before the eyelids start dropping and the posters disappear into the background.

We're clearly passionate about our approach to security awareness but keenly aware that we don't have a monolopoly on the subject. Please email me (Gary@isect.com) or comment on this blog if you have other security awareness ideas or approaches that work for you. We'll gladly acknowledge your input if we take up your ideas, and maybe something more substantive will find its way to your inbox as our way of saying thanks.

Labels: Awareness, Infosec, Risk

The Information Card Foundation is a trade body representing "a group of thoughtful designers, architects, and companies who want to make the digital world easier for you by building better products that help you get control of your personal information", and promoting the concept of "Information Cards". There are some big- and not-so-big-name backers.

Billed as "the digital version of the cards in your wallet" and "the new way to control your personal data and identity on the web", Information Cards (also known as InfoCards or I-Cards) are stored in an identity selector ("selector" or "digital wallet") on your desktop, browser or mobile device. Websites that accept Information Cards access the stored card, retrieving user identity and authentication information automatically without the user having to login in the conventional way. Other information such as your shipping address can also be retrieved automagically.

So far, this sounds reminiscent of cookies (oh no!) but presumably those 'thoughtful designers and architects' have been beavering away on the security and privacy aspects. The Information Cards Forum website doesn't actually say much about the technology, unfortunately. Perhaps they've thought through the use of powerful encryption algorithms, long keys and solid protocols. Maybe they've considered shared and public PCs, cross-site issues and more. Perhaps this time they'll get it right.

If you change your address, you only have to update it in your personal data store, and all the relationships you have established with your Information Card will be updated automatically.

OR

'If a hacker changes your address, they only need to update it in your personal data store and all the sites that use your I-Card will use the hacked version'. I wonder if the automation will be such that the user never even notices that his bank statements and goods ordered online are now being delivered to a strange PO box address half way across the country?

Use "I-Cards" to:

- login to websites with a single click

- create relationships with those you want to do business with

- manage your personal data in one place that only you and those you allow have access.

- wield the claims that other people and institutions say about you.

- prove that you are who you say you are without revealing details using trusted identity providers.

The first bullet - single click website logins - and several others on the list can be achieved already with all manner of browser-integrated password vaults.

I have no idea what bullet 4 means by "wielding claims". I understand you can wield an ax but not a claim.

The last bullet presumably implies the use of digital certificates and PKI. So that's alright then. No issues there.

I'll be interested to see how this initiative pans out. So far, it looks suspiciously like a vendor-backed "solution" looking for a market demand. Claims to the effect that the ICF will develop vendor-independent standards (for interoperability among, presumably, the ICF members) hint at the real objective here. Get something to market (or rather, 'launch the concept') and start building the I-Card brand before some idiot has the temerity to point out the flaws.

Labels: Authentication, Fraud, Hacking, ID theft, Integrity, Privacy, Risk, Secrecy, Trust

Today I've been browsing the good stuff going on over at Unified Compliance Project whose aim, as I understand it, is essentially to help organizations find and exploit alignments between various compliance requirements, eliminating duplication and hence reducing the total amount of compliance effort required. For example, implementing an ISO/IEC 27001-compliant Information Security Management System (ISMS) should simultaneously satisfy most if not all legal requirements for information privacy controls (with no additional effort), and should at least partially satisfy governance requirements arising from SOX, in addition to miscellaneous business benefits as a result of having a best practice ISMS.

One of the issues I've been pondering relates to "mandatory" requirements and obligations such as those enshrined in laws, regulations and contractual terms. It seems to me that, despite initial impressions, compliance with "mandatory" requirements may not be a simple binary condition. For a start, in most cases, the requirements are more complex than that. It is conceivable for the organization to be fully compliant with certain parts of the requirements but not so for others. Furthermore, the extent of compliance with any one requirement is often subject to interpretation, either because the requirement is ambiguous (hopefully not!) or because the organization and whomever is assessing compliance (law enforcement, lawyers, auditors, regulators, management) have their own viewpoints and prejudices. Finally, there is a chance that noncompliance might not be detected, or even if it is, it might not lead to the worst case consquences often paraded by the compliance lobby.

It's the same with speeding laws. If I break the speed limit, even by 1 mph, I am strictly failing to comply with a mandatory legal obligation. In practice, however, it is extremely unlikely I would ever be stopped for 1 mph over because (a) there are insufficient policemen with radar guns to track my every journey; (b) their radar guns have tolerance limits; (c) my speedo has tolerance limits, and the police and/or prosecutors allow me some flexibility; (d) if I am caught, there's a chance I might talk my way out of it; (e) even if I am fined, I might escape justice by fleeing the country, or I might get off "on a technicality". The situation changes for every mph over the limit - as indeed do my chances of being involved in a fatal accident. I weigh all this up every time I drive. [And yes I make mistakes: I have been fined for speeding. I didn't flee the country, I paid up and "learnt my lesson".]

So, all of this is, in fact, a risk management exercise. I assess the threat (of being caught speeding), the vulnerability (how far over the limit I am going) and the impact (the fines, the grief).

Something like SOX can be treated in the same way. Management may consciously choose NOT to be totally compliant, assessing the risks like any other business decision. Maybe they will get away with it. Maybe they can present good enough excuses to the auditors etc. to escape the full force of the law. Maybe the commercial benefits of noncompliance justify it in purely economic, if not ethical, terms.

I haven't seen this kind of perspective discussed anywhere but I am not a compliance expert. Perhaps it's old hat and I've just stumbled across somethig that is already well known. Or perhaps this stuff actually happens but nobody is willing to acknowledge it openly? I'd be interested in your thoughts.

Labels: Compliance, Risk

City of London Police officers thinking of transferring information on USB memory sticks can self-assess the risks using a questionnaire. It's a simple idea really: a police officer's responses to a few questions determine the 'risk score' leading to approval (or rather a requirement to seek approval from the relevent level of management authority, and/or to use USB sticks with additional security controls) or disapproval of the use of a USB stick for the intended situation.

Being self-assessment, the system depends on users answering appropriately and is open to deliberate abuse and inadvertent errors. However, this risk is offset to some extent by compliance procedures and structures in the police. Furthermore, it's better than nothing - without the system, police officers presumably make such decisions on a more arbitrary basis, assuming they even consider the security risks. The tool at least raises security awareness (assuming the tool is suitably promoted, for instance by being embedded in standard operating procedures).

Automating USB risk assessment is interesting at another level too. The decision tree in this instance is relatively simple, much simpler than with many other information security risks yet still complex enough to benefit from being presented as a structured questionnaire. The assessment output is based simply on the net total of scores from each question, and has only a few possible recommendations. Someone has had to write the questions and determine the score ranges and recommendations, somehow. The assessment could give inappropriate responses under certain circumstances since it does not take account of all possible situations (e.g. whether the police officer has lost numerous USB sticks before).

Contrast this to, for example, the assessment of security risks relating to a software application. There are so many elements to the risk and so many potential outputs that it is infeasible to automate the assessment - or is it? Some sort of artificial intelligence/knowledge based system is possible and could arguably give better answers than either of the two usual alternatives: asking an information security person to assess the risks or skipping the assessment altogether.

Now that would make an interesting research project for someone.

Labels: Risk

Middle-Eastern Internet services have been severely disrupted by the failure of an undersea cable linking Egypt to Italy. There are backup connections, of course, including satellite and other cable connections but their capacity is limited, hence Internet traffic in some countries in the region is experiencing delays and probably failed connections due to timeouts.

Thanks to packet switching technology and multiple routes, the Internet as a whole is highly resilient. Undersea cables can often be repaired within days or weeks. But imagine what would happen if the Internet went down, and stayed down. Not 'stayed down for a few minutes' or hours or even days, but for an extended period perhaps indefinitely.

There are various horrific scenarios that could cause this to happen e.g.:
- Widespread technology failure, disrupting the packet switching backbone;
- Deliberate action by one or more nation states in wartime, severing critical connections and/or injecting massive amounts of spurious traffic at multiple points to disrupt;
- Natural events such as solar flares/X-ray emissions from the sun, storms etc. damaging critical equipment and links;
- Cyberterrorist attacks on the Domain Name Systems or other critical elements of the Internet, perhaps combined with conventional terrorist attacks on key nodes, cables and satellite ground stations;
- Worms or other malware, in other words, software agents swamping or damaging the network;
- "Something else" - the classic contingency planning scenario. We don't know exactly what might happen. It could be something completely novel and unanticipated or a chance combination of more than one type of event, known as 'bad luck'. For true contingency planning purposes, the exact cause and nature of the incident is irrelevant: we need to be ready to cope with whatever actually happens.

With a moment's thought, the horrendous consequences of such an incident start to become clear. The developed nations are highly reliant on the Internet and would suffer economic and social consequences very quickly. Developing nations are also actively using the Internet for eCommerce and communications with the rest of the world. The Internet has penetrated even the least developed third-world countries, and disruption to first world aide programs would have consequences there too.

We're hardly on the same scale as Google, eBay and Amazon but at a local level, our own small business would suffer within days if the Internet went down. We use the Internet for marketing and promotion, sales and delivery, research and communications. There are fallback delivery mechanisms - sending CD-ROMs in the post or direct dial-up access - both of which are limited, wouldn't work very reliably and would increase our costs. We could resort to old-fashioned research methods but would miss the ready, free access to up-to-date information security news from around the globe. Our marketing and sales would suffer the most as conventional print, TV and radio advertising is far more expensive and limited in scope. That, in a nutshell, is our own risk assessment.

Larger e-enabled businesses (such as the entire financial services industry) would su=ffer immediate problems, others might hardly notice at first, at least until their suppliers, partners and/or customers started to fail. Government departments and utilities would suffer quite quckly, causing knock-on effects as the national infrastructures started to unravel. If petrol companies and airlines were disrupted, well we'd have to get used to walking or cycling to work, if indeed work existed. Civil disruption could have serious consequences for personal safety and security.

We're just a few paragraphs into this very brief overview but the 'worst case scenario' is shaping up badly. This is starting to sound like one of those science fiction doomsday stories.

On the upside, TV, radio and print media would be severely disrupted too so we might not get to hear too much about the civil disruption outside our barricaded front doors. Some of us will retreat to our caves.

What kind of contingency plans would or could you make for "the Internet is down"? Some of the more obvious things might be to retain or stockpile ordinary modems (assuming that the telephone networks are running ... but, oh dear, they are using VOIP and, no doubt, sharing a lot of the Internet technologies and links) and generally retain (or rather rebuild) the ability for non-electronic commerce and communications.

More resourceful organizations might build their own private networks to run in parallel with the Internet - such as the financial services, military and other special purpose networks. These are expensive but the greater concern is to ensure they are adequately isolated from the Internet in fact. Supposedly private bank ATM networks have been known to crash due to Internet worms so finding and closing those worm-holes must be a priority. That's definitely something we can do today.

What else would you suggest in the way of contingency measures? Any ideas you'd like to share? Just post a comment ... while your Internet connection is still running, please.

Labels: DCP, Incidents, Network, Risk

An IT systems administrator, fearing that he was about to be laid off, planted a logic bomb in his employer's systems. He survived the round of redundancies but detonated the logic bomb anyway. Fortunately for all concerned, bugs in the code prevented it working properly. In court, he was found guilty, sentenced to 30 months' jail time and found liable for $81,200 in restitution.

This story touches on quite a number of security topics:
- He was a trusted insider who went bad
- Logic bombs are a form of malware
- His office/day-job gave him privileged access to the company's IT assets
- Weak change management process controls did not prevent the bomb being installed
- The logic bomb had one or more bugs in the program/script
- Nevertheless it sparked a security incident
- He was called to account for the damage
- There was legal and presumably corporate policy noncompliance
- The risk of recurrence presumably remains

All in all, a nice multi-purpose security awareness case study.

PS The official US DOJ press release about the conviction is dated "Dec 8 2008", an integrity failure to boot.

Labels: Accountability, Awareness, Bugs, Change, Compliance, Incidents, Insider, Malware, Office, Risk

We have completed and published our collaborative white paper listing the top information security threats, vulnerabilities and impacts, along with some risk scenarios and controls, as we head towards the new year.

My sincere thanks are due to all who participated in the project, contributing directly to the shared document on Google Docs or commenting on it through the fora. I suspect there are still several points of disagreement but I hope we are all reasonably happy with the end result. I have certainly enjoyed the process and value the discussion.

Labels: Awareness, Infosec, ISO27000, Risk

Fellow infosec pros,

Tim Bass recently posted a stimulating entry to his blog proposing a top ten list of information security threats - not "risks" but threats specifically. This struck me as an interesting idea and an opportunity to add some depth to the rather banale top ten IT security risks lists that appear every new year. So, shamelessly extending a good idea, I've set up a shared document on Google Documents and now invite you to participate in a collaborative project to draw up a more meaningful list of current infosec risks, starting with separate lists of threats, vulnerabilities and impacts, then working on the risks, and finally the controls and conclusion.

If you would like to get involved, please check the shared document as it stands today and then email me (Gary@isect.com) to add you to the list of users with update access to the shared doc. Google Docs is cool but if you can't be bothered to update the doc yourself, just email me with your comments and I'll have a go. I'm particularly interested in emerging trends, as perceived by qualified information security professionals rather than journalists and marketers. What are you working on today and what do you expect to be doing in the year ahead?

I'm planning to publish the finished item on the Web under a Creative Commons license on or before Jan 1st 2008, acknowledging all contributors. Please don't ask me if you can earn CPEs for this though!

Kind regards,
Gary

UPDATE Dec 19th: the lists of threats, vulnerabilites and impacts are nearing completion so it's time to make a start on pulling things together as "risks". See the shared paper as it stands today and by all means have your say - pop a comment below if you like.

Labels: Risk

Details of audits of US Army websites and blogs run by soldiers, disclosed under the Freedom of Information Act, reveals that far more security policy breaches occur on official Department of Defense websites than on blogs. The audits were conducted by the Army Web Risk Assessment Cell, a special unit with a remit (evidently) to minimize unauthorized disclosure of sensitive military information via the Web.

It seems to me the Army was absolutely right to highlight the information security risks relating to blogging. I believe the audit results reflect the outcome of a highly successful security awareness program. If this issue had not been addressed so effectively, I'm convinced there would have been far more noncompliance issues, in other words this is a lesson to us all.

In respect of security awareness programs and policy compliance, 'the military' have a significant advantage over most of us in that the workforce is specifically trained to respect authority and follow orders - or at least, that is the classical view. In fact, I understand modern soldiers are increasingly being taught to think for themselves and operate autonomously, albeit within a highly structured (literally 'regimented') operating framework and, when necessary, at gunpoint. The traditional approach to the blogging security issue would presumably have been to send out an order banning blogging. What actually happened was more subtle: Army bloggers were instructed to register their blogs with commanding officers and pre-clear what they publish. 'Blog responsibly' is a rather softer message but the audit results seem to indicate its effectiveness in this situation.

Labels: Audit, Awareness, Confidentiality, Governance, Incidents, Infosec, Network, Risk, Trade secrets

"Hackers stole information from the U.S. Department of Transportation and several U.S. companies by seducing employees with fake job-listings on advertisements and e-mail, a computer security firm said."

The Reuters correspondent explains that victims were lured to a site with [fake] job advertisements and (presumably) phishing emails, only to have their systems infected with malware. The malware apparently evaded detection by the standard antivirus tools. Nasty.

I've long said that narrowly-targeted/custom malware is a particular threat if it slips under the antivirus silver bullet. Imagine the power of being able to select your target organization and inject your data extraction device and suck out your fill of an organization's lifeblood, with little chance of detection or prosecution. Imagine now that you are a Foreign Power or Criminal Mastermind with the money to buy such malware or the resources to recruit and train your own black squadron of evil hackers ...

Sleep well. Don't have nightmares. Leave that to us professional paranoiacs.

Labels: Hacking, Incidents, Malware, Risk

In its usual tongue-in-cheek fashion, The Register describes the Black Hat world through ten features:
1. The Black Hats form a well integrated community that shares knowledge effectively
2. Becoming a Black Hat is a career option even for those who are not super geeks.
3. There are even specialist virus tools designed to circumvent specific AV products.
4. There are SDKs for the more advanced hackers.
5. There's a market for your data.
6. There are botnets to rent.
7. Some rogue websites are very subtly managed.
8. Good hackers know how to stay safe (they stay abroad)
9. The banking system has its channels
10. Not all businessmen are entirely averse to the odd hack (on a competitor)

In the sense of "know your enemy", the article presents an interesting perspective.

Labels: Fraud, Hacking, ID theft, Incidents, Malware, Network, Risk

A neat presentation and webcast by George Spafford brought out the value of integrating IT security processes with general IT operations, risk, change and configuration management and linking to business strategy, through ITIL IT service management and COBIT. It's good to see such a broad perspective on IT security, especially one that puts the business rather than security objectives at centre stage.

More information security management resources

Labels: Infosec, Risk

As if to reinforce our recent posting regarding the insider threat and, especially, the threat from employees in trusted/privileged positions, another former system administrator has been charged with planting a logic bomb on his employer's systems, fearing that he was going to lose his job following a merger. The bomb was safely defused before it exploded but the alleged bomber's career options don't look too bright right now.

More malware links

Labels: Accountability, Incidents, Insider, Malware, Risk

Thanks to a tip-off from Gideon Rasmussen on the insider threat email reflector, I've come across a series of information security podcasts by CERT, aimed at 'business leaders'. The podcast on security Return On Investment (ROI) contains an interesting comment relating to research by "a couple of economists at the University of Maryland named Lawrence Gordon and Martin Loeb" who are said to have determined that a security control investment should only go ahead if the cost is no more than 37% of the expected return. I find this a very curious statement: from a purely economic point of view, almost any net positive return is financially worthwhile provided that (a) there is sufficient funding available for the investment (i.e. it is not outranked by other higher return investments) and (b) the projected costs and returns are realistic ... which is perhaps the issue here. Security projects in the main create returns by reducing risks and hence reducing projected future losses compared to the do-nothing option. The economists seem to be saying the security and risk professionals are seriously overestimating projected savings. They may have a point.
More security awareness and risk management resources

Labels: Awareness, Email, Insider, Risk

An audit checklist from the IT Compliance Institute (ITCi) explans what auditors would typically want to know about enterprise risk management practices. The checklist, written by the infamous Dan Swanson, offers practical advice to auditees as well as auditors. The ITCi "strives to be a global authority on the role of technology in business governance and regulatory compliance. Through comprehensive education, research, and analysis related to emerging government statutes and affected business and technology practices, we help organizations overcome the challenges posed by today’s regulatory environment and find new ways to turn compliance efforts into capital opportunities."
More risk management and IT audit resources

Labels: Audit, Governance, Infosec, Risk

Alex Hutton runs a weblog for IT risk geeks focusing on the FAIR (Factor Analysis of Information Risk) risk analysis method that his employer Risk Management Insight LLC (RMI) promotes. In his blog, Alex takes me to task for my previous blog entry about the FFIEC, FAIR enough, and complains that the NoticeBored blog only accepts comments from authenticated users. Well OK, I've relaxed the restriction to encourage more feedback although I'll be moderating comments, not to censor what people say but merely to block spam. [Alex: why didn't you email me? Gary@isect.com]
Meanwhile, I took another look at FAIR. What follows is a rather harsh and cynical critique of the FAIR method as described in the undated draft FAIR white paper, partly because the paper's author, Jack Jones, invites comment towards the end of the document: "It isn’t surprising that some people react negatively, because FAIR represents a disruptive influence within our profession. My only request of those who offer criticism is that they also offer rational reasons and alternatives. In fact, I encourage hard questions and constructive criticism". So here goes.
Right away, I was intrigued by a statement at the front of the paper regarding it being a "patent pending" method that commercial users are expected to license. Unless I'm mistaken (which is entirely possible!), "patent pending" means "not patented" i.e. it is not currently protected by patent law, or else it would presumably be labelled "Patented" and give a patent number. Judging by the content of the introductory paper, FAIR appears to be a conventional albeit structured risk analysis method so I'm not clear what aspect of it would be patentable in any event. [My snake oil-o-meter starts quivering around the 5% mark at this point.]
"Be forewarned that some of the explanations and approaches within the FAIR framework will challenge long held beliefs and practices within our profession. I know this because at various times during my research I’ve been forced to confront and reconcile differences between what I’ve believed and practiced for years, and answers that were resulting from research. Bottom line – FAIR represents a paradigm shift, and paradigm shifts are never easy." [Not only is it claimed to be patentable, but it's a paradigm shift no less! The snake oil-o-meter heads towards 10%.]
The paper defines risk as "The probable frequency and probable magnitude of future loss". [Strictly speaking, risk includes an upside too, namely the potential for future gain which FAIR evidently ignores.] FAIR considers six specific forms of loss: productivity, response, replacement, fines/judgments, competitive advantage and reputation. [Management's loss of confidence in any system of controls that fails is evidently not considered in FAIR - in other words, there is an interaction between management's risk appetite and their confidence in the control systems they manage, based on experience and, most importantly, perception or trust. These apparent omissions hint at what could potentially be a much more significant problem with the method: there is no clear scientific/academic basis for the model underpinning the method, meaning that there are probably other factors that are not accounted for. Obtuse references to complexity and this being an "introduction" to details that are to be descibed in training courses etc. further imply incompleteness in the model and hence limited credibility for the method. Snake oil-o-meter jumps to half way.]
"A word of caution: Although the risk associated with any single exposure may be relatively low, that same exposure existing in many instances across an organization may represent a higher aggregate risk. Under some conditions, the aggregate risk may increase geometrically as opposed to linearly. Furthermore, low risk issues, of the wrong types and in the wrong combinations, may create an environment where a single event can cascade into a catastrophic outcome – an avalanche effect. It’s important to keep these considerations in mind when evaluating risk and communicating the outcome to decision-makers." [I wonder whether FAIR adequately describes risk aggregation, possible geometric increase and the "avalanche effect" noted here, in scientific terms? The author accepts the need to take such things into account but does FAIR actually do so? Snake oil-o-meter swings wildly around the half way point.]
[FAIR looks to me like a practitioners' reductionist model, something they have thought about and documented on the basis of their experience in the field as a way to describe the things they feel are important. FAIR might *help* an experienced information security professional assess risks but I'm not even entirely sure of that: the method looks complex and hence tedious (=costly) to perform properly. I wonder whether, perhaps, the FAIR method should be applied by a consultant such as someone from, say, RMI? Snake oil-o-meter settles around two-thirds full scale.]
To give him his due, the author acknowledges some potential criticisms of FAIR, namely: the "absence of hard data" and "lack of precision" (which are simply discounted as inherent limitations as if that settles the matter); the amount of hard work involved in such a complicated method (which is tacitly accepted with "it gets easier with practice"); "taking the mystery out of the profession" and resistance to "profound" change (I know plenty of information security and IT managers who would dearly like to find an open, sound, workable and reliable method.) [FAIR does not appear to be a profound change so much as an incomplete extension of conventional risk analysis methods. Snake oil-o-meter creeps up again.]
The appendix outlines a "basic risk assessment" in 4 stages: (1) "Identify scenario components" ("identify the asset at risk" and "identify the threat community under consideration"); (2) "Evaluate Loss Event Frequency (LEF)" ("estimate the probable Threat Event Frequency (TEF)", "estimate the Threat Capability (TCap)", "estimate Control strength (CS)", "derive Vulnerability (Vuln)" and "derive Loss Event Frequency (LEF)"); (3) "Evaluate Probable Loss Magnitude (PLM)" ("estimate worst-case loss" and "estimate probable loss"); and finally (4) "Derive and articulate Risk". Many of these parts clearly involve estimation, implying subjectivity (e.g. "estimate probable loss" could range between zero to total global destruction in certain scenarios: the appendix does not say how we are meant to place a mark on the scale). The details of the method are not fully described. For example, the TEF figure seems to be obtained by assigning the situation to one of a listed set of categories "Very High (VH): > 100 times per year"; "High (H): Between 10 and 100 times per year"; "Moderate (M): Between 1 and 10 times per year"; "Low (L)" Between .1 and 1 times per year"; or "Very Low (VL) < .1 times per year (less than once every ten years)." Similarly, the category boundaries for worst case loss vary exponentially for no obvious reason ($10,000,000; $1,000,000; $100,000; $10,000; $1,000; $0). [The use of two dimensional matrices to determine categories of 'output' value based on simple combinations of two 'input' factors is reminiscent of two-by-two grids favored by new MBAs and management consultants everywhere. The rational basis for using these nonlinear scales and the consequent effects on the derived risk probability are not stated, nor is method for determining the appropriate category under any given circumstances (how do we know, for sure, which is the correct value?). This issue strikes at the very core of the "scientific" (theoretically sound, objective, methodical and repeatable) determination of risk. The snake oil-o-meter rises rapidly towards three-quarters.]
The appendix casually includes a rather worrying statement: "This document does not include guidance in how to perform broad-spectrum (i.e., multi-threat community) analyses." [Practically all real-world applications for risk analysis methods necessarily involve complex real-life situations with multiple threats, vulknerabilities and impacts. It is not clear whether the full FAIR method can cope with anything beyond the very simplest of cause-effect scenarios. Snake oil-o-meter creeps up to 80%]
To close this critique, I'll return to a comment at the start of the FAIR paper that information risk is just another form of risk, like investment risk, market risk, credit risk or "any of the other commonly referenced risk domains". [The author fails to state, though, that risk is not managed 'scientifically' in these domains either. Stockbrokers, traders, insurance actuaries and indeed managers as a breed use, but cannot be entirely replaced by, scientific methods and models. Their salaries pay for their ability to make sound decisions based on expertise, meaning experience combined with gut feel - clearly subjective factors. Successful ones are inherently good at gathering, assessing and analysing complex inputs in order to derive simple outputs ("Buy Esso, sell BP" or "Your premium will be $$$"). From the outset, it seems unlikely the method will meet its implied objective to develop a scientific approach. Being based on "development and research spanning four years" is another warning sign since risk analysis in general and information security risk in particular, have been studied academically for decades. Although this is an 'introductory' paper with some strong points, it is quite naive in places. The snake oil-o-meter peaks out at around 80%.]

More risk management links

Labels: Infosec, Risk

Clement Dupuis over at cccure.org put me on to a new infosec risk management handbook from an organization I haven't come across before - a Swiss organization called the Security Officers Management and Analysis Project. The handbook is described as "high level informations" containing 14 core pages on risk management, both in general and specifically in relation to information security - in fact, it probably has more to say on information security management than risk management. It aims to describe "how to plan, implement and manage an information security risk strategy and ISMS (Information Security Management System) activities." The language is rather naive in places but this could easily be due to its being translated into English, and the meaning comes through. For example: "A security officer never should be the owner of an asset. Even if this could look like a good idea, it is not. At the end the security officer would be responsible for all the assets which he obviously can not be." It is loosely structured around ISO 17799 / ISO 27001.
The accompanying Information Security Risk Assessment Guide is still in development with a 31-page draft already available. The guide looks as if it will focus on risk management in greater depth than the handbook. At the moment, it is little more than a collection of placeholders, ideas and notes to be explained/expanded later.
Both documents are released under the GNU Free Documentation License giving recipients the freedom to create and sell derivative works provided they reference the originator, retain section headings etc. SOMAP are actively inviting readers to get involved with and contribute to the project. If their appeal succeeds, the project has the potential to clear up an area of information security management that remains poorly served by other works. Although maybe a dozen information security risk management methods are in use worldwide, they seem to be the realm of specialists rather than general practice in the field.
More risk management resources

Labels: Infosec, ISO27000, Risk

The diagram comes from an excellent new white paper by Israeli security specialist, Danny Lieberman. It eloquently describes a systematic approach for assessing and addressing risks in legacy systems. It examines the question of why there are so many bugs (including defects that cause security issues) in software, and goes on to explain the derivation of threat models (using the Practical Threat Analysis tool) to design appropriate controls.
More risk management, secure development and Bugs! links

Labels: Bugs, Development, Risk

A Beaumont Hospital Home Care laptop was stolen from the car of a home care nurse, reports Metro Detroit. The nurse, a new employee, "broke hospital policy by leaving her access code and password with the computer". Doh! Data on more than 28,000 present and former patients have been compromised. "The best protection is to train and educate people who use this information as part of their jobs, to have an awareness of the things they need to do to keep this protected," said Michael Friedman, an attorney in Detroit who has handled several HIPAA cases. "It's not a sophisticated technological solution." Having covered identity theft in this month's NoticeBored security awareness module, we'll be moving on to mobile/portable IT and teleworking next month ... what more can we do to encourage organizations to invest proactively in security awareness?
More identity theft links

Labels: Authentication, Awareness, ID theft, Mobile, Risk

Although it is evidently intended to be an exam manual or study guide, the Federal Financial Institution Examination Council's IT Examination Handbook on Information Security could easily be mistaken as an information security manual. It bears more than a passing resemblance to ISO 17799, NIST, COBIT and SAS70 (amongst others) which are acknowledged as reference sources. There are "action summaries" containing key points from each section, such as this one for authentication: "Financial institutions should use effective authentication methods appropriate to the level of risk. Steps include: Selecting authentication mechanisms based on the risk associated with the particular application or services; Considering whether multi-factor authentication is appropriate for each application, taking into account that multifactor authentication is increasingly necessary for many forms of electronic banking and electronic payment activities; and Encrypting the transmission and storage of authenticators (e.g., passwords, personal identification numbers (PINs), digital certificates, and biometric templates)." A free 138 page infosec manual is not to be sneezed at.
More authentication and identity theft resources

Labels: Authentication, ISO27000, Risk

If the statistics are to be believed, up to one in six of us has suffered some form of identity theft incident or attack. Thankfully, only a minority of attacks succeed but if you or someone you know has been through the horror of a full identity theft, I'm sure you will appreciate how important it is for us all to be on our guard.
There are lots of things we can do to reduce the risk of becoming victims, but the first step (as always) is to be aware of it, realizing that the threat exists and the impacts can be severe. If fraudsters can open bank accounts, get credit cards and run up huge debts in our name, we are the ones left with bad credit ratings and the nightmare of trying to prove we are genuine and they are the fraudsters.
The management and technical streams in the NoticeBored Classic module this month raise awareness of the control measures that corporations should take to prevent their good names being abused by the phishers and to constrain the fraudsters intent on defrauding our customers.
Additional awareness materials will be made available to the general public through the Global Security Week website this month to help those organizations planning their participation in the week leading up to September 11th. Please visit the GSW website or contact us for further information.
More security awareness and identity theft resources

Labels: Awareness, ID theft, Risk

A very public industrial espionage case involving allegations that an employee tried to sell proprietary information from Coca-Cola to Pepsi is a timely reminder of the issues arising from trusted insiders. It is alleged that the employee, an administratrive assistant in the marketing function having ready access to highly sensitive information, removed it from the office and offered to sell it to Coke's arch rival. Pepsi presumably alerted the auhorities who ran a 'sting' to catch the alleged perpetrator red-handed. Even with the benefit of 20-20 hindsight, it is unclear what Coke management might reasonably have done to address this risk. Better screening and supervision of employees, maybe? Clearer policies on control of sensitive information in whatever format, e.g. "secret information must not be removed from the office"? An employee who is prepared to offer secrets for sale to a competitor seems unlikely to heed such policies. Better detective and corrective controls might perhaps have identified the exposure before things got out of hand, especially if there were preliminary incidents. Due to the implending court action, there is limited information on the details of the case, for example the news article does not state whether the accused had an exemplary record.
More links on keeping secrets

Labels: Confidentiality, Infosec, Risk, Secrecy, Trade secrets

A presentation by Mary Ann Gadziala, Associate Director of the U.S. Securities and Exchange Commission (SEC) in 2003 discussed business continuity issues arising from 9/11. In Disaster Recovery and Business Continuity Planning, she specifically noted an overriding requirement for financiaol institutions to resume vital clearing and settlement operations on the same day as a major incident, ideally within 2 hours. In practice, this implied highly resilient systems with some form of dual-live/multiply-redundant or hot standby arrangement, and significant investment in IT by the entire [US] financial services industry by April this year. The risk of systematic failure of the banking system shines out from the page.
More resilience and DR resources

Labels: Availability, Risk

The latest CSO ezine contains an eye-opening assessment of the risk of 'economic espionage' (a.k.a. industrial espionage or intellectual property theft). Secrets Stolen, Fortunes Lost recounts several case studies and makes the point that traditional security measures are no longer effective in today's e-everything world. Information security threats require different controls, and in turn this requires senior management to update their attitudes towards securing the company's crown jewels. Simply acknowledging the value of their proprietary and personal information would be a good start, let alone recognising the vulnerabilities and impacts of information security breaches.
More IPR resources

Labels: Confidentiality, Infosec, IPR, Risk, Trade secrets

A Proofpoint/Forrester survey on outbound email content scanning found that around a third of the 400+ US and UK 1,000+ employee companies surveyed have been impacted by the exposure of sensitive or embarrassing information in the last 12 months. More than a third! They estimate that around one in five outbound emails contains sensitive information that poses a legal, financial or regulatory risk. Given that not all organizations scan outbound email content, the true figures seem likely to be even higher. About half of email that should be encrypted is encrypted. [The fact that Proofpoint sells email security solutions may put a question mark over the validity of the survey although it was conducted on their behalf by Forrester Research.]
More email security links

Labels: Email, Risk

Best Practices for Secure Development may be 5 years old but the advice is still sound. "Inasmuch as a software project does not start with coding, building security into an application does not start by implementing security technologies. We will suggest an approach recommended by the existing risk management and software building practices." The paper goes on to discuss security aspects up to implementation, stopping short of security operations, controls maintenance and security aspects of end-of-life system retirement/replacement.
More secure software development links

Labels: Infosec, Risk

Further to our blog entry of April 10th, we received the following spam today:

Hey, You are recieving this email because you are a member of BlueSecurity (http://www.bluesecurity.com). You signed up because you were expecting to recieve a lesser amount of spam, unfortunately, due to the tactics used by BlueSecurity, you will end up recieving this message, or other nonsensical spams 20-40 times more than you would normally. How do you make it stop? Simple, in 48 hours, and every 48 hours thereafter, we will run our current list of BlueSecurity subscribers through BlueSecurity's database, if you arent there.. you wont get this again. We have devised a method to retrieve your address from their database, so by signing up and remaining a BlueSecurity user not only are you opening yourself up for this, you are also potentially verifying your email address through them to even more spammers, and will end up getting up even more spam as an end-result. By signing up for bluesecurity, you are doing the exact opposite of what you want, so delete your account, and you will stop recieving this. Why are we doing this? Its simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails. Its simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails, but do not believe for one second that we will stop this tirade of emails if you choose to stay with BlueSecurity. Just remember one thing when you read this, we didnt do this to you, BlueSecurity did. If BlueSecurity decides to play fair, we will do the same. Just remove yourself from BlueSecurity, and make it easier on you. Sergio Sheldon

Regardless of the veracity of the spammer's claim, regardless of the mechanism of the (alleged) compromise, I for one am not willing to take the risk. Blue Security is toast. Bye bye blue frog.

Labels: Database, Email, Risk

A new item at Silicon.com included the following quote: "'Companies must make strong and effective security practices part of their culture through awareness, education and accountability,' says Jan Babiak, head of the information security practice at Ernst & Young. 'This needs to be enforced by the CEO and the board, with organisations aspiring to implement well designed controls and fostering a security-conscious culture led from above. Without this top-down endorsement, employees will often ignore controls or worse avoid them, placing the entire enterprise at great risk.'" We'd certainly support the need for senior management's proactive support but there's rather more to the issue than that.
Take security policies for example. Policies without a management mandate are practically worthless. Policies with a clear mandate are fine, but are not in themselves effective. Policies with a clear mandate, a communications program to make sure people are aware of and understand their obligations towards the policies are an improvement ... but even that is not enough. People need to be led the extra mile to commit to the policies and, in time, adapt their behaviors to fall into line with the policies. Compliance activities can help but (yes, you guessed it) are not necessarily The Answer either - "comply or else" expletives from management can cause enormous damage to the changes necessary to achieve positive cultural shifts.
In a truly security-aware culture, people comply with security policies not so much because someone tells them to do so, but because they genuinely appreciate the need, just like an experienced driver instinctively uses mirror-signal-manouver whereas a learner driver consciously mutters the reminder under their breath. Get the security habit through awareness, training and education - but make sure your management get in the habit too. Awareness really does start at the top.
White paper on the value of security awareness

Labels: Accountability, Awareness, Infosec, Risk

*** UPDATE: Please see our May 2nd blog entry ***

A considered and thought-provoking paper from Marcus Ranum reviews the spam response system from Blue Security. The system combines the advantages of a widespread user base monitoring their inboxes for spam (which guards against malicious or inept spam reporting), with automated responses that aim to flood spammers with complaints (in effect, a denial of service attack but with self-imposed ethical limits i.e. one response per complainant). A further key feature is the manual intervention before the multi-barrel bit-guns are unleashed: the Blue Security team contacts the relevant domain admins/users to ask for an explanation, and gives them an opportunity to respond. If the spammer machine is in fact a zombie that has been compromised by a hacker and used by a spammer without the legitimate owner even being aware of the issue, the contact gives them the chance to take their machine off the web and clean it up.

Spammers are cordially invited to cleanse their mailing lists of Blue Security registrants, which unfortunately implies that other email addresses are fair game. The system designers have paid attention to the potential security implications of allowing spammers access to opt-out mailing lists, and use cryptographic techniques to obfuscate the list. However, personally, I would question the need for this function, and hence the associated residual risk, at all. Those spam recipients who do not actively opt-out are clearly disadvantaged. The merest hint of a business model starts to rear its ugly head at this point.

Active response is generally frowned-upon by the professional information security community in principle but it sounds to me as if Blue Security may have invented a workable and ethical scheme.
More email security resources

Labels: Email, Risk

A paper from the Privacy Rights Clearinghouse giving A Chronology of Data Breaches Since the ChoicePoint Incident identifies that the privacy of well over 54 million Americans has been compromised since February 2005. The list of more than 150 reported incidents (meaning an average of around three per week) is an eye opener for anyone that thinks this is not a risk.
More confidentiality and privacy resources

Labels: ID theft, Incidents, Privacy, Risk, Secrecy

A series of papers on the CERT site is well worth a look. As well as discussing the insider threat, the page has information on two risk analysis methods: OCTAVE and one I'd not heard of before: Mission Assurance Analysis Protocol (MAAP).
More information security management links

Labels: Insider, Risk

The US Defense Department has published a manual about the qualifications and experience required of information assurance professionals. The manual includes images of certain certificates, a decision that may potentially encourage some enterprising but unethical individuals to fake their qualifications. Fortunately the images are monochrome whereas the original certificates presumably (hopefully!) have color seals etc. to reduce the risk of forgeries ... so if someone approaches you claiming these qualifications, make sure to check the original certificates and do not accept FAXes or photocopies. The same point applies to other certificates by the way. Caveat emptor.
More information security management and IT fraud links

Labels: Infosec, Risk

In an interesting interview by Tony Bradley, Ed Skoudis said: "Given that many organizations have dramatically improved the patching process, we now face an even more difficult problem: user awareness. With targeted phishing and Trojan horse attacks, an unwitting user can be duped into running an attachment, surfing to a happy-looking-but-evil website, or entering information into a form that pops up on the screen. Such attacks represent a real threat to most organizations. And the real problem here is summarized well in that wonderful T-shirt: 'Because there is no patch for human stupidity' Our entire culture needs to come to terms with the risk of computer crime and how to identify and avoid its common forms. Pretty much everyone that uses computers has to learn about e-mail and website con jobs, phishing, Trojans, viruses, and other scams." Hear hear Ed!
More awareness resources

Labels: Awareness, Risk

The FAIR (Factor Analysis of Information Risk) method is described by the author as a paradigm shift - quite a claim for yet another version of what looks like an entirely conventional risk analysis process, even one that contains a “computational engine”, no less. The author admits that FAIR is “just one way of skinning the risk analysis cat”. With pseudo-scientific language, he insists on presenting his own “definitions” (actually, curious descriptions that relate particularly to information security risk, not risk in general) for the components of risk without reference to the accepted academic theories in the field. His definition of vulnerability, for example (“The probability that an asset will be able to resist the actions of a threat agent”), is 180º opposed to the normal definition, in other words high vulnerability means a high probability that an asset will NOT be able to resist a threat. The vulnerability definition goes on to confuse threat, vulnerability and control despite the author having stated that unclear terminology is one of the problems in this field. To cap it all, the method is labeled “patent pending”, a phrase with no legal standing (either it is patented or it is not - I suspect the latter).
More risk management resources

Labels: Risk

Reporting on a study of 1,000 US users of online banking by a market research firm, ZDNet UK News said "many consumers were worried that their personal information could either be stolen by hackers and phishers or sold to third parties by banks. Nearly 83 percent of those who conduct banking online reported such concerns, while 73 percent of respondents said personal information theft is a deterrent for them." By neglecting to mention the threat of ID theft from offline bank users, ZDnet implies that online banking is especially risky, although other studies have indicated the opposite (e.g. see last Friday's blog entry).
More authentication resources

Labels: Authentication, ID theft, Risk

Systems at CNN, ABC, the New York Times, DaimlerChrysler and others were reportedly either hit by the Zotob-family worms or were taken offline to apply the Microsoft patches. The decisions about whether and when to apply security patches are especially difficult in the case of critical business systems. It sounds like some organizations either didn’t get the right answers from their risk assessments or simply fouled up implementing the patches. However their contingency plans (presumably at some point involving the command ‘apply those **** patches, NOW!’) seem to have limited the damage, so far, although companies that were infected with Zotob now have to deal with the threat that their systems may perhaps be 0wn3d with keyloggers and other nasties quietly doing their stuff.
More change management resources

Labels: DCP, Infosec, Risk

Bruce Schneier discussed the race to fix and close vulnerabilities before they are publicly disclosed in his Crypto-Gram newsletter way back in 2000. The risk-time graphs are illustrative, of course, but do seem to reflect reality.
More change management links

Labels: Infosec, Risk

In a McKinsey interview, the CEO of P&G discusses various aspects of leading and managing change across the entire organization. For example, targets that stretch too far risk demotivating people [whilst those that don’t stretch enough are lame]. Difficult concepts such as ‘core business’ have to be explained patiently and frequently to some people. Similarly, the CEO of D&B says of his change strategy “The primary focus was to repair the brand, change the business model to get funds to pay for the repairs, and create a new culture. Creating a new culture was fundamental to the new strategy.” [There are clear implications for security awareness programs here!]
More change management resources

Labels: Awareness, Infosec, Risk

In a keynote presentation at the Citrix iForum conference in Australia today, hacker Kevin Mitnick : said "social engineering appeals to hackers because the Internet is so widespread, it evades all intrusion detection systems, it's free or very low cost, it's low risk, it works on every operating system, leaves no audit trail, is nearly 100 percent effective, and there is a general lack of awareness of the problem."
More [anti-]hacking and social engineering links.

Labels: Audit, Awareness, Hacking, Risk, Social engineering

The European and Pacific Stars & Stripes reports that an airman based in Japan has been convicted by a court martial for trying to hack PC files on the base using a password cracker program he downloaded from the Internet. It seems the man also uploaded a password file from the base to a personal web server through the Internet, with the risk of third party interception en route.
More anti-hacking resources

Labels: Authentication, Hacking, Risk

Perhaps as a result of the Californian law requiring disclosure of security breaches involving personal data on Californian residents, several incidents involving the loss of backup tapes in transit between the primary and backup sites have come to light since 2004. Given the sensitivity and volume of data on the tapes, and the fact that they are being handed to (albeit trusted) third parties for transportation, it is perplexing to discover how few organizations apply encryption ['encoding' and 'proprietary formats' don't count - these are just weasel words], even in financial services. The latest example of this kind of incident involves Iron Mountain Inc., a backup specialist that hit the news over another similar incident a few months before. Why is it that the possibility has escaped otherwise quite comprehensive risk analyses? Presumably it is not explicitly covered by SAS70 or the auditing standards and has simply slipped under management’s radar, until now.
More physical security resources

Labels: Incidents, Infosec, Physical, Risk

Someone's resignation letter, whether it is actually true or not, makes fun reading but has a real sting in the tail. Read to the end and think about this the next time you appoint or dismiss a systems administrator or indeed anyone else with privileged systems access.

Labels: Infosec, Integrity, Risk

Hurray! It's patch Tuesday! Microsoft has released patches for a clutch of security issues including one affecting Outlook Web Access and another affecting Outlook Express. It's important to keep up with security patches to minimize the risk of compromise by worms or hackers attacks. If you/your organization uses OWA or Outlook Express, or indeed other vulnerable software that has just been patched, you may only have hours or days before exploits begin causing problems. Act now to prevent breaches.
More email security links

Labels: Email, Risk

The US Department of Defense clearly faces some serious information security risks. According to this presentation about security policies by ex-military man and honeynet security guru Lance Spitzner, the DoD recognizes seven levels of threat. “T1: Inadvertent or accidental events e.g. tripping over the power cord. T2: Passive, casual adversary with minimal resources who is willing to take little risk e.g. listening. T3: Adversary with minimal resources who is willing to take significant risk e.g. unsophisticated hackers. T4: Sophisticated adversary with moderate resources who is willing to take little risk e.g. organized crime, sophisticated hackers, international corporations. T5: Sophisticated adversary with moderate resources who is willing to take significant risk e.g. international terrorists. T6: Extremely sophisticated adversary with abundant resources who is willing to take little risk e.g. well-funded national laboratory, nation-state, and international corporation. T7: Extremely sophisticated adversary with abundant resources who is willing to take extreme risk e.g. nation-states in time of crisis.” Another way of looking at this is as a maturity model for information security. Is your organization ready to face threats at level T4 or T5? Can you afford to address T6?
More risk management resources

Labels: Infosec, Risk

US CERT issues a handy email update of vulnerabilities announced in the previous week. They mention patches, workarounds and other actions to help mitigate risk.
More infosec risk management resources

Labels: Email, Infosec, Risk

"Security isn’t only about protecting your network from external threats; it’s also about protecting against threats from within. The first step to security is awareness; therefore, it’s important that all your employees know not only the potential threats but also how to recognize and prevent such threats. Education and awareness empowers each employee with the knowledge of his role in protecting the organization’s network. This, in turn, will go a long way toward mitigating risk." Well said Doug Schweitzer! This week's Processor magazine has several interesting articles on security awareness and policies.
More risk management and security awareness links

Labels: Awareness, Infosec, Network, Risk

Various infosec professionals have been commenting on the threat posed by new forms of malware used to install cryptic rootkits or spyware without alerting the user to their presence. It seems not all antivirus and antispyware software can detect these. There is a distinct possibility that a very specifically targeted chunk of malware could infect an organization or even an individual person, perhaps to wreak havoc with their systems or to disclose sensitive information. Call me paranoid if you like but the pieces are falling into place.
More malware links and risk management links.

Labels: Malware, Risk

"The crash of a critical legacy system at Comair is a classic risk management mistake ... the legacy system failed, bringing down the entire airline, canceling or delaying 3,900 flights, and stranding nearly 200,000 passengers. The network crash cost Comair and its parent company, Delta Air Lines, $20 million, damaged the airline's reputation and prompted an investigation by the Department of Transportation." Executives stalled all attempts to replace the old crew scheduling system until eventually it failed in service. Reading between the lines of the story, however, it is not clear whether the proposed replacements would have represented even greater risks.
More risk management links here

Labels: Infosec, Network, Risk

Distributed Denial of Service attacks are being used to extort money from on-line businesses. This is hardly hot news but various experts in a Computerworld piece say this is an increasing threat. More interesting is the emergence of commercial tools to mitigate DDoS attacks, giving victims an alternative way to spend their money (I would be surprised if there were no free tools with the same aim out there, at least in development by the wonderful public-spirited open source community).
More risk resources

Labels: Availability, Risk

CERT has released a 45-page report into the threat of sabotage by insiders. As one might expect from CERT, it focuses on the threat to the IT elements with an emphasis on critical infrastructure although it includes examples in commercial settings.
More risk management resources here

Labels: Insider, Risk

ComputerWorld points out that new/changing laws such as those concerning the protection of vital information in effect create new liabilities (we would say "impacts") and new threats such as employees or business partners failing to comply with the new laws - in other words they affect information security risks.
More information security risk management and legal resources

Labels: Infosec, Law, Risk

There seems to have been a rash of security incidents involving the loss of backup tapes lately. Computerworld is now reporting that Time Warner lost an entire shipment of data backups en route to its off-site storage. The Register outlined a handful of similar incidents, pointing out that identity thieves would love to get their hands on backup tapes containing credit card numbers and other personal details, especially as so few are encrypted.
More risk management, physical security, privacy and confidentiality links

Labels: Physical, Privacy, Risk, Secrecy

A report by the UK Home Office reveals that only one of 13 CCTV systems studied directly produced a statistically significant reduction in crime relative to comparable control areas without CCTV. This runs counter to the general perception, and the implication of previous Home Office and Police statements, that CCTV deters city-center crime. The report has implications for the cost-benefit and risk analysis of CCTV in private/commercial settings.
More risk management and physical security links

Labels: Physical, Risk

The gist of this news article is that a fraud involving the theft of customer details by call-center operators in an Indian company may discredit the whole Indian off-shore/outsourcing market. Sorry, I don't buy that argument. The truth is that IT fraud is a risk in ALL countries. I see no reason to believe that India is inherently more risky than anywhere else - in fact, the increasing level of interest in our security awareness products from Indian IT companies suggests quite the opposite to me. At the risk of over-generalizing, India seems very well aware of the importance of information security.
More IT fraud links and IT governance links

Labels: Awareness, Fraud, Governance, Incidents, Risk

This is part of a factsheet from the UK Institute of Directors advising non-executive directors on (a) how to go about asking questions to the Board or other managers about IT strategy and security; and (b) the types of question worth asking. [I particularly liked "Has your business assessed the risk of getting a reputation for slackness in security?"!]
More IT governance resources

Labels: Governance, Risk

Find out (roughly) how vulnerable you are to identity theft by completing this automated survey. Practical advice on how to reduce your risk is given at the end. [This might be a useful security awareness site for your intranet, and for your friends and relatives].
More IT fraud resources

Labels: Awareness, Fraud, Risk

The VISA Cardholder Information Security Program includes a security standard designed to ensure that all VISA merchants conform to a common security baseline, plus the associated training, validation and certification processes.
More standards and laws links here

Labels: Infosec, Law, Risk

Modern dedicated or multifunction printer/scanner/photocopier devices typically contain embedded hard drives used to cache and re-sequence document images. A piece in Canadian cNews (no longer online) points out the risk of accidentally disclosing images of ‘everything you’ve ever printed’ [a bit of journalistic license there, we think] when machines are sold or returned to the leasing companies [or, for that matter, are ‘serviced’ by unethical engineers or hackers].
More physical security links here

Labels: Physical, Risk

Antivirus vendor Sophos offers a neat little 64-page booklet explaining viruses and other forms of malware in simple terms. It is a useful document for non-technical users - not a sales glossy - and includes practical advice for reducing the risk of infection.
More malware links here

Labels: Malware, Risk