Critical Control 20: Security Skills Assessment and Training to fill Gaps

Published: 2011-10-28
Last Updated: 2011-10-28 17:37:45 UTC
by Daniel Wesemann (Version: 1)
1 comment(s)

There's two parts to this control - one focuses on users, the other on security and IT staff.

Keeping your users abreast of current threats and how to steer clear of these dangers is definitely important. But in today's compliance-driven corporate world, the average staff member already has to sit through many trainings and e-learnings on topics ranging from corporate records management to HR policies to anti bid-rigging rules, etc. Hence, the first hurdle that every security training has to overcome is to actually get the initial attention of the audience.

If you had the choice between attending a "Security Awareness Training", and a presentation called "How to keep your kids safe on the Net" .. which one would you join? The latter can impart just about the same lessons as the former, but hardly anyone in the audience will catch on to the fact that you are teaching them to be careful on the Net just as much as you empower them to watch their kids.

In other words, as in all marketing endeavors, packaging is everything. Once you have the users' initial attention, the easiest way to keep them interested is by using real life examples from your own company or institution. Even if the audience happens to be already aware of a certain attack or threat, and would otherwise be bored, they will always be interested in what REALLY happened, close to home.

You might find out that users come with three levels of security clue:

1. Those who just don't know better
2. Those who do know better, but take shortcuts, don't care, or have an "it won't happen to me" attitude
3. Those who do know better, and stick to being careful

For Group #1, train them, patiently and repeatedly
For Group #2, make a gory example out of one or two trespassers. The others will catch on. If you can't get away with gory examples "pour encourager les autres", then patiently treat Group#2 like Group#1.
For Group #3, thank them for every risk that they spot and report, and empower them to act as coaches for Group #1 staff in their team

SANS Control #20 and the SANS "Securing the Human" project ( are two good starting points for further information.

Now, for training of security and IT staff. For most readers of this ISC diary, this will mean yourself, and maybe also people that you manage in your team. With training budgets for 2012 currently getting drawn up in many companies, and the economic situation making it unlikely that the budget will be a brimming bucket of money, now is a good time to honestly assess where the gaps are and how to most effectively fill them.

Ask yourself:
- Do I have the know-how to oversee the implementation of some or all of the 20 critical controls? Where are my gaps?
- Would I have the know-how to actually implement, hands-on, some or all of the 20 critical controls? Where are my gaps?

If you are a manager of a security team, I'd recommend you do the above assessment for each of your staff members. Not everyone can be an expert in everything. But, sadly, the recent years of paperwork compliance (SOX, the old FISMA, etc) have bred a large caste of security staff whose main and only competency seems to be "to track open issues". In the past couple months though, senior executives have definitely started to catch on to the surprising delta between what the "security compliance report" suggests, and what the reality is.

SANS training is doing a great job teaching people (and even managers :) hands-on security skills of value. But this isn't a SANS training commercial. Just an encouragement with emphasis to all security specialists out there to make sure that you keep your skills up to snuff. And to all managers of security specialists, that you make sure to have the right people for the job on the team.

Because one thing's for certain: The job ain't gonna get any easier anytime soon.


1 comment(s)
ISC StormCast for Friday, October 28th 2011

Critical Control 19: Data Recovery Capability

Published: 2011-10-28
Last Updated: 2011-10-28 01:08:31 UTC
by Russ McRee (Version: 1)
0 comment(s)

 Incident responders may not always keep the business continuity planning (BCP) or management (BCM) team on their speed dial but I can tell you it’s worthwhile to do so in consideration of Critical Control 19: Data Recovery Capability.

Successful data recovery is as much a part of reliability as it is security, so embrace the process as paramount to successful response. Whether it is a significant outage from operational data loss (the SQL server ate that data) or that moment that leaves as all shuddering and queasy (attackers have tweaked our data and it is no longer reliable) you have to know you can recover.
This control does mention testing restorations from backups twice, once in the measurements section and once in the procedures and tools section, but I humbly submit that every possible measurement and procedure should be tested quarterly at a minimum. 
Much as one might with incident response, drilling the recovery/restoration process is critical. And not tabletop exercises; I mean real data to real systems in real scenarios that mimic your production environment. Clearly testing the process directly in production may be difficult but a staging (or dev/test) environment is ideal for this testing.
Unfortunately for them, you need someone expert in the restoration/recovery process on-call as part of your incident response planning. 
Here’s a scenario to chew on. Imagine responding to a reported incident where critical system configurations have gone missing (operational snafu, not malicious). The next day, you respond to another incident where a particular configuration has put an environment at risk and the extent of exposure needs to be identified. As a result, you ask for the offline configuration only to learn that it went missing in the incident from the day before, and that restoration was not immediately possible due another unrelated systemic shortcoming. Aargh!
How to avoid this? Short answer: test, drill, validate. Regularly. More than regularly on critical systems. 
Another ugly problem that comes out of incident response but is directly affected by or is subject to data recovery practices is the "when did we get pwned?" scenario. This is where backup design is so important. 
As the control mentions, you have to factor for operating system, application software, and data recovery. Yet each of these three is influenced by full, differential, and incremental methodology, depending on need, scheduling, and planning as well as the retention period.
Can you conduct a successful, relatively painless recovery today if you found out you were compromised two weeks ago and all data since is suspect? If no, keep working towards that goal. There is a light at the end of that tunnel, and it may not be a train. ;-)
Been through this? Succeeded? Failed? Let us know via the comment form.
Russ McRee - russ at holisticinfosec dot org - - Twitter: @holisticinfosec


0 comment(s)


Diary Archives