Cicso’s recently published the results of a survey of Public Sector CIOs showing a surge in intent to allocate budget for security in 2014. This comes as no surprise, given the rise in both external and internal threats to organizations. As part of an overall security strategy, organizations need to constantly assess the ever-changing state of their security.
So what’s the best way to truly know what state your security is in?
Most organizations focus on reactive measures, such as periodic reviews of current states. There are a number of issues with this methodology:
- Your security is only as good as your review frequency – How often is your organization performing reviews? Assume you’re secure about that often.
- Your review can become the security! – let’s pretend you’re only concerned with the security of a single critical application. You’ll, no doubt, setup a checklist of what settings and parameters need to be looked at. But that’s not security. Security is a process that should occur on a per-user/login/transaction/etc. basis.
- The current state may not be the insecure one – Someone can modify security to allow inappropriate access, perform the act threatening to the organization, and then put security back the way it was before.
- The review itself may be flawed – Your review of security may only look within the one critical app in vast detail of its security settings. But what if changes were made to the file system or database the app resides in allowing someone to make a copy of the data so they can hack against it later in the safety of their own home?
The only real way to know whether your organization is secure or not is to proactively auditing the changes in security in real-time, allowing you to always keep security in a “known state”. By auditing changes all aspects of your environment – file storage, databases, collaborative systems, and most definitely any directory service you are using as the source of all security – you will have the ability to not only know the current state of security, but also the changes made to it as they occur.
Let’s use one other example – a simple security guard in an office building. His job is to ask for your ID and check you in before you enter the building. He’s keeping the building security in a constantly “known state”. There are no exceptions to building access he isn’t aware of – why? Because he’s not “reviewing” security at the end of the day to see who came into the building (way too late to react anyway). Instead, but watching every change in the environment (in this case, someone entering the building), security is maintained.
To be truly secure, you must maintain a known state and the only way to do this is by constantly auditing the changes made to your your applications, systems and security.