1. Intervention
- Actions:
- response to incidents
- assist attacked victimes
- plan reactions
- reassess processes
- Strategic interest:
- technological independance
- curatives competences
- international constraints (cybercrime convention, eEurope, i2010, ... )
- confidentiality of attacks
2. Actions
- CERT (Computer Emergency Response Team) / CSIRT (Computer Security and Incident Response Team)
Real incident response and handling, not only an alerting structure is needed. The CERTs/CSIRTs should be teams being able to go on site and assist victimes to get up again, as soon as possible.
A proposal CERT organisation structure is:
- "National" coordination center Mainly focused on "international" relations with FIRST, TF-CSIRT, CERT-CC, etc.
- LERSs (Local Emergency Response Structures) The local teams tightly linked and knowing their communities, doing the real work of emergency and incident handling.
- Abuse Team(s) An Abuse team is a response facility, who professionally handles "Internet-abuse" reports or complaints (e.g. spam, viruses, offensive mails, etc.), on a relatively large scale.
- "Red Team(s)" "Red Teams" are pentesting groups offering interested business parties penetration tests to validate their network security. "Red Teams" normally want to share their knowledge and as such enhance the common knowledgebase with research in security related areas.
3. The global picture
- CERT/CC (CERT Coordination Center) The CERT® Program is part of the Software Engineering Institute (SEI), a federally funded research and development center at Carnegie Mellon University in Pittsburgh, Pennsylvania. Following the Morris worm incident, which brought 10 percent of Internet systems to a halt in November 1988, the Defense Advanced Research Projects Agency (DARPA) charged the SEI with setting up a center to coordinate communication among experts during security emergencies and to help prevent future incidents. This center was named the CERT Coordination Center (CERT/CC). While they continue to respond to major security incidents and analyze product vulnerabilities, our role has expanded over the years. Along with the rapid increase in the size of the Internet and its use for critical functions, there have been progressive changes in intruder techniques, increased amounts of damage, increased difficulty of detecting an attack, and increased difficulty of catching the attackers. To better manage these changes, the CERT/CC is now part of the larger CERT Program, whose primary goals are to ensure that appropriate technology and systems management practices are used to resist attacks on networked systems and to limit damage and ensure continuity of critical services in spite of successful attacks, accidents, or failures ("survivability"). More on the name CERT (from their FAQ): CERT is not an acronym. It is a name an a registered service mark. ("CERT" and "CERT Coordination Center" are registered with the U.S. Patent and Trademark office as service marks of Carnegie Mellon University.) You should not define "CERT" as an acronym; but it is appropriate to note in your text that the CERT/CC was the first computer security incident response team.
- FIRST (Forum of Incident Response and Security Teams) FIRST is the Forum of Incident Response and Security Teams. The idea of FIRST goes back until 1989, only one year after the first CERT was created after the infamous Internet worm. Back then incidents already were impacting not only one closed user group or organization, but any number of networks interconnected by the Internet. It was clear from then on that information exchange and cooperation on issues of mutual interest like new vulnerabilities or wide ranging attacks - especially on core system like the DNS servers or the Internet as a critical infrastructure itself - were the key issues for security and incident response teams. Since 1990, when FIRST was founded, its members have resolved an almost continuous stream of security-related attacks and incidents including handling thousands of security vulnerabilities affecting nearly all of the millions of computer systems and networks throughout the world connected by the ever growing Internet. FIRST brings together a wide variety of security and incident response teams including especially product security teams from the government, commercial, and academic sectors.
- TF-CSIRT
The TF-CSIRT Task Force promotes the collaboration between Computer Security Incident Response Teams (CSIRTs) in Europe. The main goals of this Task Force is to provide a forum for exchanging experiences and knowledge, to establish pilot services for the European CSIRTs community and assist the establishment of new CSIRTs.
The TF-CSIRT Task Force is established to promote the collaboration between Computer Security Incident Response Teams (CSIRTs) in Europe. The main goals of the Task Force are:
- to provide a forum for exchanging experiences and knowledge
- to establish pilot services for the European CSIRTs community
- to promote common standards and procedures for responding to security incidents
- to assist the establishment of new CSIRTs and the training of CSIRTs staff.
- TI (Trusted Introducer) The Trusted Introducer or TI provides European CSIRTs (Computer Security Incident Response Teams) with a public repository that lists all known European CSIRTs and explains about the TI's accreditation service. The Trusted Introducer is an initiative of the European CSIRTs. CSIRT teams or "CERTs" are teams (or functions) within an organisation that deal with computer and network security incidents. CSIRTs try to prevent such incidents from happening, and coordinate the handling of such incidents when they do occur. The CSIRTs cooperate worldwide to combat computer cracking and other IT related crime. In Europe joint CSIRT activities are undertaken within a cooperative body called TF-CSIRT. To cooperate efficiently and swiftly when security incidents occur, a certain level of mutual trust is needed between CSIRTs. An important pre-requisite for mutual trust is shared and accurate operational knowledge about one another. The TI accreditation service is meant to do just that: facilitate trust by formally accrediting CSIRTs that are ready to take that step. For a CSIRT to proceed from the status of "listed" to the status of "accredited" they need to go through a formalised accreditation scheme. Once "accredited" they gain access to the restricted TI repository: there they find the details about their fellow accredited CSIRTs, and several value-added services like readily downloadable contactlists and PGP-keyrings, secure discussionfora, automatic RIPE Database IRT-object registration and so on. A crucial service that is part of the accredited status of CSIRTs is maintenance: in a four-monthly cycle the actuality of data is verified with the accredited CSIRTs to prevent these data from going out-of-date.
- E-CoAT (European Cooperation of Abuse fighting Teams) E-coat aims to further the cooperation of Internet abuse fighting teams of network/information service providers in Europe, and jointly produce tangible results that will benefit its constituency and beyond and help them more effectively combat Internet based network/computer abuse. To further these goals, e-coat will co-operate with existing anti-abuse and CERT fora in and outside Europe. E-coat is a non-profit non-commercial collaborative organisation with minimum overhead – the latter to enable also emerging and small providers to join e-coat and thus increase the effectiveness of the cooperation.
4. CSIRT a definition
"A CSIRT is a team that responds to computer security incidents by providing necessary services to solve them or support their resolution, and tries to prevent any computer security incidents within its constituency or responsibility"
CSIRTs primarily focus on the response to ICT related security incidents on behalf of one or more stakeholders. The stakeholder(s) of a CSIRT are its constituency. The constituency should be regarded as the customer base of a CSIRT.
In order to mitigate risks and minimise the number of responses required, most CSIRTs also provide preventive services for their constituency. They issue advisories on vulnerabilities in various systems and on viruses and similar threats.
The following abbreviations are commonly used for CSIRT-like structures:
- CERT© or CERT-CC (Computer Emergency Response Team)
- CSIRT (Computer Security Incident Response Team)
- IRT (Incident Response Team)
- IRC (Incident Response Capability)
- CIRT (Computer Incident Response Team)
- SERT (Security Emergency Response Team)
4.1. Benefits
- A central coordination point for ICT-security within the organisation
- A systematic respond facility to ICT-incidents taking appropriate steps
- A support to the constituency recovering quickly and efficiently from security incidents and minimise loss or theft of information and disruption of services
- An information gathering during incident handling to better prepare for handling future incidents and to provide better protection for systems and data
- A proper dealing with legal issues that may arise during incidents
- A knowledge exchange within the constituency
4.2. Types
The following illustration shows the correlation between the types of CERTs and their focal points. In most cases the different types of CERTs are identified by their constituencies, but other effects also influence the constituency. Because of this, the diagram also portrays the relevance of the products used and areas of responsibility.
5. A CSIRT howto
The main focus is to deliver quality, service and good information as soon as possible.
- What kind of CSIRT is needed ?
- What is its constituency ?
- Are there services, tooling, staffing and methods already available? What kind of information is processed ?
- What do the interested parties expect, what kind of products are going to be delivered ?
- What does the environment look like, what other CSIRTS can be cooperated with ?
- What kind of organisation is needed ?
- What is the responsibility ?
- Who are the sponsors and what is the budget ?
5.1. Organisation
- Tips for the road
-
- A flat organisation It keeps the organisation very flexible and gives you space to move towards a new direction and other products if necessary.
- Open and honest communications, enthusiastic people It is important for a self-learning organisation that people should be free to make mistakes and learn from them. Remember, you can only do it with a complete team where everyone is respected for their opinion. A golden rule is first to say what you want to say and talk later about improvements to the way you said it.
- Team members with an ex-commercial background They are highly customer driven and are used to quickly making products from early ideas. Also, working with contractors in the starting phase can give you more flexibility but needs a real leadership role for management.
- Strong project management skills, especially in the early phases Planning is essential, take small steps and don't forget to celebrate your milestones. It is also necessary to deliver good management reports which are needed to keep the commissionaires satisfied and give them confidence.
5.2. Finance
Sound funding is the basis for a successful project. A good plan makes finding funds easier. It takes a lot of effort, but it keeps sharp and forces to recheck the project plan and estimated schedule. It encourages a mature and independent way of handling a project.
The budget should cover most of these (if needed):
- 24x7 support
- Independance
- Tailor-made advisories (up to the minute)
- Prevention of ICT-security issues (awareness)
- Incident response (onsite)
- Knowledge and advice centre on ICT Security
- Cooperation with national and international groups
Example bugdet for GOVCERT.NL (per year) : 2M € operational + 400K € "Waarschuwingsdienst" => ~2.5M €/y
5.3. Services
CSIRT services can be grouped into three categories:
Reactive services
These services are triggered by an event or request, such as a report of a compromised host, wide-spreading malicious code, software vulnerability, or something that was identified by an intrusion detection or logging system. Reactive services are the core component of CSIRT work.
- Alerts and Warnings This service involves disseminating information that describes an intruder attack, security vulnerability, intrusion alert, computer virus, or hoax, and providing any short-term recommended course of action for dealing with the resulting problem. The alert, warning, or advisory is sent as a reaction to the current problem to notify constituents of the activity and to provide guidance for protecting their systems or recovering any systems that were affected. Information may be created by the CSIRT or may be redistributed from vendors, other CSIRTs or security experts, or other parts of the constituency.
- Incident Handling
Incident handling involves receiving, triaging,3 and responding to requests and reports, and analyzing incidents and events.
- Incident analysis
Essentially, incident analysis is an examination of all available information and supporting evidence or artifacts related to an incident or event. The purpose of the analysis is to identify the scope of the incident, the extent of damage caused by the incident, the nature of the incident, and available response strategies or workarounds. Two sub-services that may be done as part of incident analysis, depending on the mission, goals, and processes of the CSIRT, are
- Forensic evidence collection
- Tracking or tracing
- Incident response on site The CSIRT provides direct, on-site assistance to help constituents recover from an incident. The CSIRT itself physically analyzes the affected systems and conducts the repair and recovery of the systems, instead of only providing incident response support by telephone or email (see below).
- Incident response support The CSIRT assists and guides the victim(s) of the attack in recovering from an incident via phone, email, fax, or documentation. This can involve technical assistance in the interpretation of data collected, providing contact information, or relaying guidance on mitigation and recovery strategies.
- Incident response coordination The coordination work may involve collecting contact information, notifying sites of their potential involvement (as victim or source of an attack), collecting statistics about the number of sites involved, and facilitating information exchange and analysis.
- Incident analysis
Essentially, incident analysis is an examination of all available information and supporting evidence or artifacts related to an incident or event. The purpose of the analysis is to identify the scope of the incident, the extent of damage caused by the incident, the nature of the incident, and available response strategies or workarounds. Two sub-services that may be done as part of incident analysis, depending on the mission, goals, and processes of the CSIRT, are
- Vulnerability Handling
Vulnerability handling involves receiving information and reports about hardware and software vulnerabilities;5 analyzing the nature, mechanics, and effects of the vulnerabilities; and developing response strategies for detecting and repairing the vulnerabilities.
- Vulnerability analysis The CSIRT performs technical analysis and examination of vulnerabilities in hardware or software. This includes the verification of suspected vulnerabilities and the technical examination of the hardware or software vulnerability to determine where it is located and how it can be exploited.
- Vulnerability response This service involves determining the appropriate response to mitigate or repair a vulnerability. This may involve developing or researching patches, fixes, and workarounds.
- Vulnerability response coordination This service can involve communicating with vendors, other CSIRTs, technical experts, constituent members, and the individuals or groups who initially discovered or reported the vulnerability.
- Artifact Handling
An artifact is any file or object found on a system that might be involved in probing or attacking systems and networks or that is being used to defeat security measures. Artifacts can include but are not limited to computer viruses, Trojan horse programs, worms, exploit scripts, and toolkits.
Artifact handling includes analyzing the nature, mechanics, version, and use of the artifacts; and developing (or suggesting) response strategies for detecting, removing, and defending against these artifacts.
- Artifact analysis The analysis done might include identifying the file type and structure of the artifact, comparing a new artifact against existing artifacts or other versions of the same artifact to see similarities and differences, or reverse engineering or disassembling code to determine the purpose and function of the artifact.
- Artifact response This service involves determining the appropriate actions to detect and remove artifacts from a system, as well as actions to prevent artifacts from being installed. This may involve creating signatures that can be added to antivirus software or IDS.
- Artifact response coordination Activities include notifying others and synthesizing technical analysis from a variety of sources. Activities can also include maintaining a public or constituent archive of known artifacts and their impact and corresponding response strategies.
Proactive services
These services provide assistance and information to help prepare, protect, and secure constituent systems in anticipation of attacks, problems, or events. Performance of these services will directly reduce the number of incidents in the future.
- Announcements This includes, but is not limited to, intrusion alerts, vulnerability warnings, and security advisories.
- Technology Watch The CSIRT monitors and observes new technical developments, intruder activities, and related trends to help identify future threats.
- Security Audits or Assessments
This service provides a detailed review and analysis of an organization’s security infrastructure, based on the requirements defined by the organization or by other industry standards that apply.
There are many different types of audits or assessments that can be provided, including
- infrastructure review
- best practice review
- scanning
- penetration testing
- Configuration and Maintenance of Security Tools, Applications, and Infrastructures This service identifies or provides appropriate guidance on how to securely configure and maintain tools, applications, and the general computing infrastructure used by the CSIRT constituency or thea CSIRT itself.
- Development of Security Tools This can include, for example, developing security patches for customized software used by the constituency or secured software distributions that can be used to rebuild compromised hosts.
- Intrusion Detection Services CSIRTs that perform this service review existing IDS logs, analyze and initiate a response for any events that meet their defined threshold, or forward any alerts according to a pre-defined service level agreement or escalation strategy.
- Security-Related Information Dissemination
Such information might include
- reporting guidelines and contact information for the CSIRT
- archives of alerts, warnings, and other announcements
- documentation about current best practices
- general computer security guidance
- policies, procedures, and checklists
- patch development and distribution information
- vendor links
- current statistics and trends in incident reporting
- other information that can improve overall security practices
Security quality management services
These services augment existing and well-established services that are independent of incident handling and traditionally performed by other areas of an organization such as the IT, audit, or training departments. If the CSIRT performs or assists with these services, the CSIRT's point of view and expertise can provide insight to help improve the overall security of the organization and identify risks, threats, and system weaknesses. These services are generally proactive but contribute indirectly to reducing the number of incidents.
- Risk Analysis CSIRTs performing this service would conduct or assist with information security risk analysis activities for new systems and business processes or evaluate threats and attacks against constituent assets and systems.
- Business Continuity and Disaster Recovery Planning Based on past occurrences and future predictions of emerging incident or security trends, more and more incidents have the potential to result in serious degradation of business operations. Therefore, planning efforts should consider CSIRT experience and recommendations in determining how best to respond to such incidents to ensure the continuity of business operations.
- Security Consulting CSIRTs can be used to provide advice and guidance on the best security practices to implement for constituents’ business operations.
- Awareness Building CSIRTs may be able to identify where constituents require more information and guidance to better conform to accepted security practices and organizational security policies.
- Education/Training Topics might include incident reporting guidelines, appropriate response methods, incident response tools, incident prevention methods, and other information necessary to protect, detect, report, and respond to computer security incidents.
- Product Evaluation or Certification For this service, the CSIRT may conduct product evaluations on tools, applications, or other services to ensure the security of the products and their conformance to acceptable CSIRT or organizational security practices.
5.4. Communication
- Know your target groups When setting up a CSIRT it is important to think about communication with your target groups. Every organisation has target groups and for a CSIRT these are your constituents and other stakeholders.
- Plan your communication to target groups
A strategic communication plan is based on the strategy your organisation has chosen for the next 3-5 years. The main issues to consider are:
- Analysis
Use several models such as SWOT or PEST to analyse the organisation and environment.
- What are the key communication problems for the next few years ?
- How to get everyone to know you ?
- Are there any risks to watch for ?
- Corporate communication Think about the mission statement, corporate identity, corporate image and branding.
- Target groups These will not only be constituents, do not forget to include other stakeholders in the environment, such as the media, commercial organisations in your field and international contacts.
- Communication objectives & strategy
- What would the team like to achieve with their target groups ?
- How would it like to be seen by them ?
- Key message This is the message all communications should have.
- Communication means Which means will fit with both target groups and objectives? To attract new constituents, one needs more than a website and a corporate brochure. It is important to spend time in personal contact and specific attention.
- Analysis
Use several models such as SWOT or PEST to analyse the organisation and environment.
5.5. Legal aspects
Access to legal advice for CSIRTs is critical; without it, the team can unknowingly take inappropriate or illegal actions that can result in the team’s demise. Small teams who do nothave easy access to legal advice are at a great disadvantage. They should at least seek legal advice prior to beginning service and when making major changes in policy or operating procedures, if at all possible.
Management of legal issues involving CSIRT teams means exercising a coherent view of the legal issues that the team faces. Legal advice should be given by legal experts who are experienced in this area and understand technical terminology and issues that form the basis of daily CSIRT work. It is important that legal advisors are enlisted for the long haul (years instead of months) because the amount of domain-specific knowledge needed by your advisors should not be underestimated.
Topic areas for legal advisors:
- Contract Analysis Contracts should be checked for legal validity, especially those with customers. This not only includes finding statements that are legally meaningless, non-binding or just plain wrong, but also identifying omissions that can be legally harmful to the CSIRT.
- Service Definition and Quality Assurance The service is what you sell (guarantee, promise, whatever applies) to the constituency. Service definition and quality assurance are accountable, especially when things go wrong. So whatever it says, it should be legally sound.
- Policies and Procedures Policies and procedures should be checked for legal pitfalls, especially as policies and procedures often include statements that involve strong positive action such as sanctions. Such actions always inherit the danger of being opposed to some other laws.
Example: Your policies may say that you are going to fire somebody if he violates your disclosure policy. This may very well cause a conflict with local or institutional laws: in some countries it’s trivial to fire an employee, in other countries it’s very hard.
Example: Suppose you have stated in your procedures that you will only exchange sensitive data with your constituents in an encrypted way. Suppose your constituent is in trouble and wants you to fax the data to them. If you refuse, even for the best of reasons, although you may comply with your own procedures, it is very doubtful that you are meeting your service goals for that constituent. It would be best if you knew in advance whether the encryption was a legal requirement or simply a preferred practice.
Example: Another instance of the above example would be the constituent who does not want to support encrypted communication at all and does not have the necessary tools available, yet wants to exchange sensitive information.
- Waivers and Disclaimers Disclaimers are found in many places: service descriptions, policies, Web sites, outgoing email, etc. All disclaimers should be checked for legal validity, or at least they should have a legal purpose. A mythical example of an added disclaimer due to case law is the wonderful story about a little dog being warmed inside a microwave oven after having come home soaking wet. The dog died, and the oven manufacturer was found liable in court. Because of the case, the manufacturer added some appropriate phrases to the oven manuals. Or so the myth goes. Example: You often read in contracts, on signs in a coatroom, or other places that such and such is in no way accountable for something going wrong (e.g., if your coat is stolen). This seems an easy escape but rarely is: often lawyers laugh at such phrases and say that it’s up to the judge to decide. However, on the other hand, these escape clauses are not entirely useless; for if they are not there, the case may be even worse from lack of due care. The CSIRT might require its customers to sign waivers that limit the liability of the CSIRT in some way (e.g., “best effort,” “due diligence,” or “industry standards”). Legal advisors may be able to suggest areas in which the CSIRT might most appropriately make use of such waivers. The same review and caveats that apply to disclaimers should be applied to the creation of waivers.
- Non-Disclosure Agreements CSIRT staff may be required to sign non-disclosure agreements (NDAs) both when starting and leaving employment with the CSIRT. If so, the same will certainly apply to part-time staff and visitors who share the details of the CSIRT work. This may also apply to the cleaning staff, guards, and others. Before implementing an NDA, it should be reviewed by a legal advisor to ensure it is appropriately worded and matches any organizational policies.
- Proactive Measures
Suppose a law enforcement agency legally requests information from a CSIRT. Is the CSIRT prepared for that event and for what may happen afterwards? Suppose the CSIRT is summoned for a liability case. Is it prepared for that? Being prepared for such cases presupposes two things:
- doing your job the way that you said you would do it (in your service specifications) and demonstrating “due care.” What “due care” means also depends on your local laws and should be discussed with your legal advisors
- documenting and timestamping all significant events in your workflow and the workflow of incidents occurring, within reasonable boundaries Example: If your CSIRT only saves logs for a specific time and has stated so publicly, and there is no law against this, nobody can complain if logs are not available any more once this time has passed. On the other hand, consider the opposite case: imagine that after the specific time an audit finds data that should have been deleted much earlier. This then might be the foundation of a liability case of its own. The second point (documenting and timestamping) is where the proactive measures come in, and the legal advisors should advise or provide insight for approaches that support the needs of the CSIRT. Essentially the task is to identify the minimum level at which the CSIRT events (especially the incidents) should be documented, and also to identify the right way of doing this. The “minimum” is meant as that which is required by law, and that which may be required (or come in very handy) in obvious court cases. The “right way of doing it” means that the evidence (the documents, logs, archives, etc.) should be gathered so that it will receive high marks for completeness (within the set purpose), logic, and reliability when the material is legally requested or is investigated in a court case. This is less trivial than it sounds. An example will help clarify this point. Example: In a Dutch case (State vs. Ronald O., 1993-5) where an alleged intruder was on trial, the evidence put forward by the prosecution included a set of logs. The logs still had original page numbers on them, but several pages were missing; they had been discarded a long time before by the party from whom the logs came because they contained no relevant data. Since pages were missing, the defense pleaded that evidence was being withheld. The judge dismissed the defense’s plea. However, a better way of handling possible evidence (the log files) would have prevented this issue from arising.
- Liability
A liability issue is anything that you say, do, or write; or that you do not say, do, or write; and for which people may want to sue you, with a reasonable chance of success in court. The matter of liability is dependent on local law and legal in character that legal advisors must be consulted on the subject. Proactive action is needed to prevent liabilities. The kind of action needed may vary depending on the context. The context can range from liabilities arising from the content of signed contracts (e.g., unable to provide service in line with your defined service definition by lack of availability of the service) that a CSIRT has with its constituents to those relating to information disclosure or omission.
- Use standard contracts with legally “safe” phrases
- Remove all statements from your service definitions, quality-of-service levels, and policies that may be untrue, difficult (or impossible) to meet, or are legally unclear
- Make legally sound disclaimers
- Define your workflow, policies, and procedures; and install appropriate documentation, enforcement, and control processes such that it is possible at all times to prove that due care is taken during your operations
- Insure your service if the risks exceed the cost
- Consider using waivers to limit or prevent the CSIRT from being liable for certain obligations or damage inflicted on a customer or other CSIRT
- Disclosure of Information
Information disclosure has the biggest potential of generating liability for a CSIRT. Disclosing information is not just about writing reports and advisories; giving advice on the telephone is also disclosing information. Apart from these “predictable” disclosures, there are also unpredictable disclosures:
- legal court orders
- information leaks from the CSIRT (whether from trusted experts or current or former employees)
- information gained through intrusion (physically or through the network)
5.6. Processes
A basic process design:
- Relevance First question to ask: "Is it relevant information?”
- Identification Is the source trusted, can it be checked, can we start writing immediately? A written procedure on how to check the variable sources is important to have.
- Classification Define rules to treat classified, public, etc. information. It's important to be very cautious about information and how to handle it, what can be made public or whether there are any disclosure rules attached to it. It's also very wise to have a list of all the different organisations and describe the rules that that organisation uses for distributing information.
- Filtering The CSIRT should have a list of all the software and servers that are used by their constituents, to be able to filter the information according to relevance to their customers, so customers only get the information that concerns them.
- The media matrix After the filtering step to assure that it is relevant for the constituents, use a media matrix. It describes what actions to take, based on two axes. One is the objective impact, technical assessment, is it really a vulnerability and does it really have an impact on the product and impact on security. The other axis is subjective impact, what is the feeling of the public and is it picked up by the media. So this axis is a more subjective approach to the information.
Make use of severity levels for incidents, like the following:
- High: patch immediately
- Medium: within the same day
- Low: patch it but do so in the regular patch sequence
Example spreadsheet from GOVCERT.NL:
- Output Most often the output is an advisory.
A complete process flow
5.7. Technology
- Physical location Should be a physically isolated building or part of a building.
- Network Best would be a "stand alone" network.
- Desktop Separate firewall and anti-virus scanner for the laptops. Thorough daily scans and reports on the whole system, with a log server. Encrypted systems, destkops, laptops, etc.
- Mailing list software Be careful with the configuration, you don't want to send out malicious or infected emails.
- Email There are PGP and PKI solutions for encrypting and signing emails. Most CSIRTs have a PGP procedure to do the signing on personal trust. A PGP remailer, which encrypts and decrypts email sent to a confidential mailing list is another interesting option.
- Reporting Start collecting data and reporting on sent advisories, caught viruses on the email relay and the anti-virus scanner right at the beginning. This is also very beneficial for the security scans produced for the constituents. Also think about setting up a separate logging server to collect and preserve all logging information, to be used for reporting and troubleshooting and to see if the system code has changed (tripwire products)
- CMS If used should be very secure and robust, but give enough freedom to place content.
- Templates These are important for producing advisories and alerts. They provide a handle for producing the same layout and force you to ask yourself the right questions and fill in the content.
- Others
- a waiting room database tool To administer the advisories that are waiting for more info before producing an advisory or letting other members of the team write an advisory about that topic. It is also very useful for handing over the active tasks to the next person in line.
- a "photograph" tool to producde a databse with the configurations and systems the constituency
- a ticketing system (RT)
- a CRM (Customer Relationship Management) tool
5.8. More tips
- Seek cooperation with a trusted partner, to review the security policy, network design and physical architecture
- Implement all the steps required for the local privacy policy Ensure that you know what information will be stored on what system and under what conditions.
- Apply a multi layered security strategy (belt-and-braces) in the network topology
- Do not allow direct network connections from internal to external and vice versa
- Use a separate test network and don't mix them up: use different coloured LAN cables
- Use disk encryption for your laptops
- Install PGP and/or PKI on laptops for signed and trusted e-mail
- Go through a complete risk analysis study
- Rethink twice what could happen before implementing
- Implement fail-safes Try to have backup systems and at best a backup site.
- Test backups with a full restore and check the documentation
5.9. Planning
- For swifter implementation:
- Gather and share knowledge & expertise with CERTs that are developing similar activities
- Integrate the activities of the alerting service into the systems and processes of your CERT
- Start by sending advisories to build credit first: be quick and accurate!
- Stay in close contact with your target group (i.e. with user groups) to improve the quality of your alerts
- Start a Newsletter service for people who are not specifically interested in alerting
- Establish good contacts with (national) press in case escalation is needed
- Use a phased approach. That allows to practice alerting and thereby build credit before asking the public to contribute.
- Think BIG, start small and scale fast!
