I created a basic computer security incident response presentation a while ago. It outlines the benefits and concerns involved in the creation of teams and mechanisms tasked with action after computer-related security issues.

Note that a CSIRT doesn’t replace the regular R&D and operations groups, but is a supplementary body, coordinating both preparation for and response to things like information breaches and attacks.

By its very nature, a CSIRT has to have a strong mandate and a lot of authority in an organization; this requires management support, and a lot of it, in addition to a really close and positive relationship with all other teams involved in these activities. Examples of these are the network security organization, various helpdesks, human resources, email administrators and others who may be attached as auxiliaries to a CSIRT.

In order to get this sort of mandate, you will have to coherently demonstrate an overall risks-rewards scenario. So:

  • What are the threats to my organization and what will I lose if I do nothing about them?
  • What does my organization stand to gain (productivity enhancements, etc.) by dealing with these in an organized manner?

In my experience, the most positive elements of a CSIRT is that it allows coordinated vulnerability management and a coherent, organization-wide process for things like patching systems and updating security software, in addition to being a locus for discussion and cooperation by various technical groups (the Windows server administrators, UNIX, email, network, security, etc.) This sort of collaboration tends to extend beyond the direct focus of the CSIRT’s day-to-day activities.

A few examples of the logic I use:

csirt.png

Simply put, if you don’t do anything, and something goes wrong, the results can vary from your looking stupid to someone going to jail. There’s a fine line between FUD and realistically outlining possible consequences, and IMHO Sarbanes-Oxley has been a bit overused by enthusiastic security people, but I would clearly outline things like data protection laws or past Bad Things happening when organizations suffered attacks (i.e. British Airways losing several thousand workstations to Blaster.)

csirt11.png

I think this is a pretty good outline of what it is I’d propose as a CSIRT’s roles and competence. In your case, you might want to play up the final business value a bit more, maybe put numbers on the risk reduction.

If you contact me and ask nicely, I’ll be glad to share the whole thing.

 

Or: when not to swat flies with a Buick. So hi ho, hi ho, onto my soap-box I go.

At one point, someone at one of my early employers decided that I would be “the security expert.”  OK, fine.  I attended a meeting with a manager in Germany. At the time, a group of people within the company was attempting to leverage a combination of their excellent and pioneering security and cryptography products, as well a relevant selection of Internet solutions from external suppliers. Among these was the then-brand-new Netscape proxy server. My meeting partner immediately began to enthuse about the possibilities of monitoring the activities of all employees, monitoring this, logging that, etc. etc. etc. I had to bring him down from his tree and remind the guy that if your people are spending all day looking at porn, that’s a leadership and motivation issue that you can’t solve technically.

Shortly thereafter, when I installed the first of these things at a client site, I left their brand-new leased line up and running, and had the proxy log connections as a test. The next morning I noticed a huge amount of logs; as it turned out, one of the IT guys had stayed late and downloaded inordinate amounts of fairly nasty porn. My client’s IT manager had made it clear that he was of the same persuasion as the German colleague described above; the staffer would doubtlessly have been fired, so I asked a colleague of his to quietly inform him that all connections were being logged explicitly as of now, and deleted the logs (this was before we handed over the infrastructure so I wasn’t technically outside my authority.) I don’t suppose he did it again, and I still think this approach was better than costing the man his job over some naked girls and farm animals and whatnot.

In the meantime, I have gotten into numerous discussions about this and similar topics. What I call the “powerpoint mentality” often seems to take hold of many managers of all backgrounds, ranging from freshly promoted former engineeers to MBAs from top schools with years of experience. By this, I mean that frequently things look good in a theoretical presentation, but in real life they break down. The main culprit among these is the habit of small minds and bad leaders to try to quantify what they do not understand, such as human nature. When you quantify something, you can start to restrict it so it fits your world view. Unfortunately, it often leads you to neglect responsibility for intangible issues that you just have to play by ear based on skill and experience–in German, this is called “Fingerspitzengefuehl”, or “finger-tip feeling.”

I see parallels to the discussion about limiting sysadmin privileges. To my discredit, I am prone to lumping this argument in with the category of “control-freak managers.” I shouldn’t do that, as there are good reasons for proper privilege separation and audit trails. However, my bugaboo with this is that it very often (a) goes to extremes, seeking to artificially restrict and control what a sysadmin does (in direct contravention of one of my rules of Getting Stuff Done: “hire good people, pay them a lot of money, and trust them.” Within reason, of course.) And (b) lets crappy management off the hook by focusing on technical staff as the primary threat to the enterprise. I tend towards inexcusable knee-jerk reactions, not being very informed about statistics of privilege abuse by technicians, and having seen far too many incidents of managerial abuse of privilege not to be cynical whenever the topic comes up.

At risk of ranting and rambling, I’d like to draw a parallel to security professionals uncovering incriminating evidence on other employees, and being informed by HR either that no action be taken due to the “suspect’s” standing (i.e. a profitable trader), or that employment and privacy laws be knowingly broken in the course of the investigation, as the potential fine, should this violation be discovered, would be far outweighed by the likely financial loss to the company if the incident were not investigated with all available means. All this in all likelihood (no paper trails please) with the tacit knowledge of C-level executives. I’m aware of both of numerous occurrences of both of these.
I leave it as an exercise to you, dear reader, to decide where the line lies between restricting and auditing employee and sysadmin activity, and doing the same for managers who seem to have trouble with basic right and wrong.

 

This post is password protected. To view it please enter your password below:


 

Standard issued by the Clinical Laboratory Standards Institute (CLSI), document ID “Auto-11P”. One of several recent attempts to specify standards for IT security in medical devices. Covers network security, separation of privileges, development best practices, as well as review techniques. Many of its elements are very basic (e.g. explanations of encryption and authentication technology, what is a firewall, etc.) and rely on common sense, but then again the medical and IVD fields are about 10 years behind the technology curve as security is concerned.

The doc is targeted at 3 sensible groups; vendors (i.e. R&D and support staff), end-users and customer IT managers. There is provision made for the idea of protecting against data theft, although the prime issue in this area is data corruption by malware and other attacks. As you are probably aware, the main problem facing medical device manufacturers is the inability to consistently patch systems to respond to newly discovered threats and vulnerabilities; every “change” to the nature of a system requires a complex and expensive re-validation process.

Naturally, the solution to this is “don’t develop purely oriented towards functionality”. In plain English, don’t scrounge around for technology that just happens to be available, such as Windows XP, without proper design criteria and a fundamental evaluation and risk assessment process (what will the long-term cost be due to the fact that we used crappy technology to start out with…) I’m hoping that the suggestions and requirements in this doc will narrow down the solutions chosen for development platforms such as diagnostic data stations to technologies considered secure and reliable by other industries–which have more experience in secure development.

Unfortunately, as it’s a commercial document I can’t post the text here, but it is available at http://webstore.ansi.org/ansidocstore/dept.asp?dept_id=57 and via CD-ROM subscription from CLSI.

From the press release at http://www.clsi.org:
“Newly proposed Clinical and Laboratory Standards Institute (CLSI, formerly NCCLS) document IT Security of In Vitro Diagnostic Instruments and Software Systems; Proposed Standard (AUTO11-P) specifies technical and operational requirements, as well as technical implementation procedures related to security of IVD systems (devices, analytical instruments, data management systems, etc.) installed at a healthcare organization. This document provides a framework for communication of IT security issues between the IVD system vendor and the healthcare organization.”

 

I once helped put together and run a computer security incident response team. The team was unique in drawing a specialist or two from each of the major technical and risk management groups (Windows server support, mail infrastructure, firewall & network security, network, etc.) as well as from the existing financial fraud and internal affairs investigation organization.

Much of our time was spend developing the individual policies and procedures outlining the IRT’s responsibilities, defining authority and basically selling ourselves to both management and the line teams–an investment that paid off pretty well; by involving everyone closely in what we were doing, we received a lot more cooperation than we could have expected had we just been imposed on the company as a fait accompli. In the end we ended up handling several high profile cases pretty successfully. I’ll be writing more on this topic in the future, but the following is a partial outline of what I see as an IRT’s basic responsibilities:
- threat investigation, categorization and warning/announcement

- vulnerability management (a monthly vulnerability board meeting to discuss these)

- investigation of external attacks, bank-related fraud, phishing, etc.

- internal forensics (e.g. information leaks, sabotage, harassment)

We started out essentially from scratch and within the space of about 6 months had a fully functioning organization. Lesson learned: always handle budget and authority first. Lesson #2: PR is as important as substance. Frequently, PR (i.e. keeping people informed clearly and concisely of threats, vulnerabilities and your activities) IS substance, there’s no reason why you can’t combine the two.

Another thing we figured out is that every CSIRT is a tailor-made affair; even in a large corporation, some massaging and diplomacy is required to exert authority in subsidiary companies — again, involving their staff and management and keeping them informed goes a long way towards fostering acceptance.

A few of the links that got us started:

- CERT and it’s “creating a CSIRT” page:

http://www.cert.org/

http://www.cert.org/csirts/Creating-A-CSIRT.html

- The CMU CSIRT handbook:

http://www.sei.cmu.edu/publications/documents/03.reports/03hb002.html

- RFC 2350, Expectations for Computer Security Incident Response:

http://www.ietf.org/rfc/rfc2350.txt

 

The health IT security wiki is a community portal with links to and information about standardization groups, laws, and other interesting bits related to healthcare and medical IT security. It’s a pretty good starting resource and incorporates pointers to a lot of the compliance-relevant and technical standards in this field, which is pretty far behind financial services and other areas in terms of having a firm grasp on information security.

Many of the topics are ones I have worked on in recent projects, and as such I will be posting more links to related groups, as well as descriptions of what they do (I got to write a little tiny bit of the CLSI Standard for IVD IT Security, whee!)

http://www.healthitsecurity.net/wiki/index.php?title=Main_Page

 

Forwarded by a colleague, supposedly found on a Russian spyware forum a little while ago. This is as close to a formal software requirements doc as I’ve seen for an exploit / trojan. It describes in reasonably structured detail the elements required for development of a spam botnet trojan.

Click here to download

 

This is a good vulnerability scanning & pen testing site. Information is categorized and well organized; tools are complete, and the templates/formats are ready to go for most customers with only minor edits required.

I especially like the mindmap format (FreeMind) of the pen testing framework. Other resources include

  • Tools
  • Default passwords
  • IT security news
  • Application ports
  • OS-specific information
  • Database scanning (fairly basic, but still a useful start.)

http://www.vulnerabilityassessment.co.uk

Two thumbs up.

© 2012 Chakraborty Software Suffusion theme by Sayontan Sinha