Day 2 - Preparation: Building a Response Team
For the second day of Cyber Security Awareness Month we will look at how to build a response team. If you are part of a response team and have any anecdotes you can share please send them to us via our contact page. Here are some questions that frame what we are looking for:
- What does your team look like in terms of skill sets?
- How did you recruit and staff it?
- Does it answer to the CIO side of your organization? If not, then where is it?
- Do you outsource your team?
- How do you train them?
- What does your budget look like?
We will update this diary with your comments and thoughts throughout the day, so start sending them in.
UPDATE 1
A reader wanting to remain anonymous sent us this:
I run an IR team for a large global manufacturer. We have six full-time handlers and another ten or so guys that split duty between investigation/analysis work and traditional security operations. We have a mix of:
- former sysadmins/network admins with a wide breadth of experience
- ex-military infosec analysts
- greyhat penetration testers/reverse engineers
- coders / perl/python/ruby monkeys
We have folks that are good at identifying anomalous activity, good at understanding how different enterprise apps communicate and log, good at obtaining information from hosts, good at staring at pcaps, log analysis, scripting, malware analysis, etc.
Most are in a salary range of a high-end sysadmin. We have a semi-formal training program to get new folks ramped up on tools and the network / infrastructure we are defending, and expect them to learn the basic "PICERL" process with time, since it seems to be better caught then taught. We report to a security operations manager, who reports to the CISO, who reports to the CIO, etc.
I find locating tried-and-true handlers is difficult - we end up having to take folks with a security slant and turn them into handlers. Love to hear suggestions on what kind of experience/backgrounds have been more successful in recruits from other managers.
Marcus H. Sachs
SANS Internet Storm Center
Low, slow, distributed SSH username brute forcing
Koos writes in with some logs of distributed SSH scanning with the following characteristics. Usernames are being brute forced starting at "aaa" and incremented. This is being done in a distributed manner with almost perfect synchronization between the scanning hosts. Over the last 32 hours, his system received 216 login attempts of which 138 attempts were from unique IP addresses. Obviously, the attacker is trying to avoid the popular SSH banning scripts by going under the banning thresholds of these programs. At peak, there was only 20 total attempts per hour.
Note that the username guessing did not actually cover all possibilities. Perhaps it is a bug, or by design. The last letter was not being exhaustively tested - only about 10 of 26 letters were being tested in the last position, and it seemed to be randomly picked.
Update: An anonymous reader at a university submitted logs that correlate very nicely to the above activity - it looks as if the scanning was occuring at the same time against both targets. His logs covered 30 hours, with 600 login attempts from 184 unique IP addresses. 98 of the IP addresses match between both scans! This scan showed the same characteristic in that the last character in the username was not being exhaustively enumerated - it still seems as if it was being incremented with a random offset. Also, this was a larger dataset and I found that the middle letter in the username was not being exhaustively tested either (although it was very close to complete). The final interesting point is that it appears the same username was being tested simultaneously against both targets, but it was from different source IP addresses. So this tells us something about how the scanning computers are getting their "work packages".
Comments