Saturday, April 20, 2013

8 tips for a security incident handling plan



8 tips for a security incident handling plan

Incident handling is a vast topic, but here are a few tips for you to consider in your incident response

1.    Have an incident response plan. It is, of course, the most obvious advice, however you would be amazed at the number of organisations that "haven't quite got around to it yet".
It doesn't need to be 400 pages long (nor should it be half a page most likely) but documenting your incident response plan and distributing it up front can make a massive difference when the inevitable occurs.
2.    Pre-define your incident response team and make sure it draws from multiple disciplines. A good incident response team should not just consist of IT or security people (though they undoubtedly need to be a strong core), but should also include PR, HR, Legal and executives to name just a few.

Team people. Image from Shutterstock 

For instance, not involving the PR team could result in external communications that are more damaging than the breach in the first place.
Make sure each member of the team is briefed on their involvement and expectations. Watch that list of team members, however. It gets old quickly as people leave, go on vacation or just forget what they signed up for.
3.    Define your approach: watch and learn or contain and recover. We have seen great examples of this in the news recently. When an incident occurs and is verified - for instance a hacker compromising one of your web servers - you need to make the call on whether to recover as quickly as possible or to watch the attacker and learn.
You need to make this policy decision upfront because it requires good preparation, executive support and a skilled team to manage the risk. Most organisations will (and should) focus on containing the damage and recovering business systems.
Detailed forensics and observing the attackers is often too great a business expense for many firms, but don't give up entirely on capturing evidence - you never know when you may need it later.
If you are a target likely to come under persistent long term attacks from adversaries (perhaps a nation state, a competitor or a hacking gang that you have riled somehow) learning more about your adversary to help build future defences can make a lot of sense.
You should not venture down this path unless you have the resources (people, duplicate systems, network infrastructure for suitable containment) to execute it successfully and it absolutely requires executive buy-in or you will find yourself out of a job very quickly if it goes wrong.
Make this decision up front, discuss the risk attitude of the business and alter your incident response process appropriately. Of course, you won't watch and learn on every attack, so identify the two paths and when you will use them.
4.    Pre-distribute call cards. Another common mistake is to depend upon your normal communication infrastructure in the event of an incident.
Imagine that the LAN stops working, no-one knows anyone else's number and email doesn't work. It will be pretty tough to handle an incident in that situation.
Decide up front communication methods, choose a call bridge or similar and then distribute details to each of the stakeholders.
5.    Forensic and incident response data capture. This goes wrong a lot. During and after security incidents, pressure can be high and there is a tendency to rush, which - of course - means mistakes are made.

Magnifying glass on files. Image from Shutterstock
You need to ensure that you have comprehensively captured the right data and logs without taking up hours you don't have - it's not a trivial balance.
In particular, define how you will capture notes (I like a lined, dated paper notebook which is easy for courts to get their heads around) and evidence.
Do you run Volatility to capture memory? Do you power off the machine and take an image of the disk to capture as much as you can before the attack shuts down? Decide in which instances you will follow each path and build a toolkit ready to go.
6.    Get your users on-side. Incident response is not just an 'IT thing'. Make sure your incident response links up with your organisation's acceptable use policy and security awareness program.
You want your users to know how to tell you if they think an incident is occurring. In particular, system administrators, application owners and data owners should know how to contact you if they spot something unusual. The incident response process can then be spun up (or spun down if it's a false alarm) quickly. Don't just write the policy and leave it on the intranet somewhere.
7.    Know how to report crimes and engage law enforcement. Certain types of incident may require you to report to law enforcement but often when such an opportunity arises no-one knows exactly how to do it.
From having your web server hacked to the theft of credit card details or IP it pays to understand the process and requirements in advance. Check out Naked Security's quick guides on reporting computer crimes and find out who your representative is before you need them.
8.    Practice makes perfect. The process can be documented but when it comes time to use it the bridge is enabled and no one connects or knows what to do. Stage an incident and have your team dial in and work through the mock scenario.

Wednesday, April 10, 2013

Industrial Control System Standard of Practice


Industrial Control System Standard of Practice


All.Net presents our standards of practice decision framework for securing industrial control systems. These decisions provide an overarching basis and many specifics surrounding what we currently view as a reasonable and prudent approach to addressing information protection for industrial control systems. While there may be many other approaches that might also meet the need, we hope that these will provide guidance and discussion within the community, and we use them as a starting point in our practice to help guide consistent quality and performance within our own team and in customer engagements.

This content is part of a process used by our affiliated companies as developed over many years. We identify these issues, characterize the environment, and apply these decision points by interacting with clients and applying our expertise to help form overall architecture and its component parts. Typically, decisions are reviewed both internally and externally in an iterative fashion so that as we discover things that require changes, those changes ripple through the overall standard to keep it up to date and relevant.

In many cases, this standard of practice is used starting with an as-is review, identifying a desired future state, doing what, by then, is a relatively straight forward gap analysis, and then characterizing a workable transition plan for the organization. In our more agile approach, we undertake only an initial and periodic as-is and future state analysis, understanding that the reduced time and cost in assessment leads to more resources available for acting on the results, and that planning is less certain and less permanent when we are moving at a faster pace.

Tuesday, April 9, 2013

A peek inside the ‘Zerokit/0kit/ring0 bundle’ bootkit




Features: 
- Start of *.exe, *.dll (*.dll is in a pre-alpha stage) and shellcodes in a context of the chosen process. 
- Start of files from a disk and from the memory* (start from memory is in a pre-alpha stage). 
- Start of files with specified privileges: CurrentUser and NT SYSTEM/AUTHORITY. 
- Granting the protected storehouse** for off-site (your) ring3-solutions for permanent existence in the system without need of crypt. 
- Survivability of the bundle, down to a reinstallation of the system. 
- All the components are stored outside of a file system and are invisible to OS. 
- Intuitively clear interface of admin-panel. 
- Protection against the abstraction of Admin Panel. 
- Impossibility of detection of the bundle in the working system by any of known AV/rootkit scanner, owing to the use of author’s technologies of concealment. The unique opportunity of detection exists only at loading with livecd or scanning of a disk from the other computer. Thus the opportunity of detection is also extremely improbable, as own algorithms of a mutation are used.
* Start of a file from the memory allows to bypass all modern proactive protection and AV-scanners, that is, there is no necessity to crypt a file. 
** Protected storehouse is the original ciphered file system in which the certain quantity of files which will be started from the memory at each start of the OS can be stored.


The bundle consists of: 
- Bootkit. It is responsible for the start of the basic modules at a stage of loading of OS. 
- Driver. It is responsible for all infrastructure and implements componential business-logic on the basis of so-called mod (functional unit). That is, the driver is not a legacy driver (monolithic), and consists of the set of mods that allows to operate the bundle with maximum of flexibility, and to protect (hard to reverse), update and expand it. 
- Dropper. At the current moment it brake out all machines with the patches till January, 8th, 2011, except for XP x32/x64 where reloading is initiated. If the systems distinct from XP have latest updates reloading is initiated as well. 
- User friendly Admin Panel.
Also I will give support to clients within the subscription fee. I provide them with: 
- Development of new functionality and 
- Development of new exploits for the dropper. 
- Perfection of algorithms of concealment and penetration of the system.
High scalability of zerokit allow to develop additional mods and to complicate business-logic of all infrastructure.
Zer0kit have flexible update subsystem and can live in system as long as possible. Also zerokit has considered and provable logic to prevent the lost of bots.
Supported OSes: 
– Windows XP SP1-SP3 (x32, x64) 
– Windows Vista SP1-SP2 (x32, x64) 
– Windows 7 SP0-SP1 (x32, x64)