For all the effort we put into securing our corporate systems from a technical perspective, it's still the case that the bulk of the effort associated with a comprehensive security posture relies on helping our people understand their role in security efforts day by day.
For this reason, security training programs have been implemented far and wide, but does training really fit the bill? When we talk about training, we are really referring to rote repetition of concepts, ideas, and steps in process. This can be very helpful when teaching your staff the value of a check-list to ensure that each step was completed, but what about when the end-user needs to actually interact with the situation and make a decision?
This is where education takes over... When we teach ourselves how to evaluate the evidence at hand and make a decision, that's the heart of real education. The best way to educate your workforce on security concepts is to give them the tools and information, and then step back and let them teach themselves.
This requires more preparation on the part of the instructor, but it will empower your workforce to evaluate the situations they encounter every day and make effective choices... and wasn't that the whole point of the exercise in the first place?
Training versus Education
Is your change-management process working? Do you even have one?
Do upgrades to your corporate systems happen because of deliberate
reflection and defined testing, or do changes get introduced “on-the-fly?” The
latter is more common that we all care to admit, but it can be a costly way to
do business when an untested change causes an entire system to behave in
unexpected ways--sometimes things even cease to operate.
The value of the productive hours
lost is part of the real cost of poorly-implemented changes to systems, so make sure that all changes are planned, approved, tested, and
documented, along with some form of a back-out strategy. You never know... things don't always work out quite the way we expect, now do they?
Consider forming a Change Management Committee and make sure that senior
members (who might be construed as stake-holders) from across your organization
participate in its activities.
Finally, communicate, communicate, communicate: Make sure that
everyone who needs to know about an upcoming change actually gets the memo.
Surprises can get ugly.
Have You Defined Standards for Each System?
Unlike policies and procedures, which are mandatory in
nature and apply to all members of the organization, a standards document is
specific to the information system that it belongs, and sets forth goals for
implementation of that system.
As we all know, there’s more than one way to
implement a system, and keeping track of how your organization has chosen to
set up controls in each application is a great idea. Still, core concepts of security implementation at your organization can be identified and codified for each system, regardless of the endless variety.
These standards documents
can be as detailed or as high-level as you wish, but they will always be
specific to the system and will be advisory in nature. Make sure that your security teams can demonstrate how day-to-day activities relate to the code of behavior in each standard.
Who Owns the Data vs. Who Maintains the Data
In the age-old battle of data and systems administration,
organizations must understand who actually owns the data contained in the
applications. Data center staff may well administrate the programs and the
operating system upon which the programs depend, but their role in ownership is
limited.
Access to sensitive data must be authorized by the
department or group who create and maintain the actual content of the system.
They alone should decided who gets access to the system, since they know all
their departmental players, and are best suited to determining who has an
actual business need for access.
Systems maintenance staff are the perfect choice for
maintaining the software that runs the application, the operating system that
supports the application, and the hardware that houses the application. They
are not the best folks to decide who gets access to the data.
Are Your Policies Just Credenza-ware?
How often are your policies and procedures reviewed and
updated? If you’re having trouble answering this question, chances are you’ve
got a credenza-ware problem, a not-uncommon malady in our current business
environment.
The cure for this condition is to decide at what intervals
policy and procedure documentation will be reviewed, and by whom. Even if no
changes are to be made, a quick review and validation that everything is
up-to-date is a powerful tool. Keep the date of last review and revision handy
too.
The reason for this is simple—anyone can pay to have
policies built to satisfy a regulatory requirement, but if you want to get true
value out of them, you have to see your corporate policies, standards, and
procedures as something more like a mirror, meaning that they reflect a
commonly understood reality of your corporate life.
Envision your policies as hierarchical, with a few broad
policies at the top, and more specific sub-policies and procedures supporting
them. Then take the time to allow your standards and procedures to flow from the
initial design that you’ve chosen.