It’s a simple fact. Good security doesn’t just happen. You need to have a very specific set of knowledge to effectively secure your information assets.
The knowledge you need falls into five discrete categories: policies, data, people, systems, and events.
Lack of information in these categories can have many consequences – all of them bad. A few of the more glaring problems you’ll encounter include allowing people the ability to 1) access more than they should, 2) perform tasks or roles for which they are not authorized by the business, or 3) inadvertently leave sensitive data unprotected.
Also, you may 1) not notice that your security implementation has changed, 2) be unable to determine who made changes or when, and 3) not know that you have been successfully or unsuccessfully attacked.
In short, lacking knowledge in any these categories opens your company to security breaches and/or compliance infractions.
At first glance, the information for these “must know” categories might seem overwhelming — a body of knowledge that is too hard for anyone to gather and manage.
Never fear! In addition to explaining the categories, I will also provide tips for how to find and manage the information you need.
Must-know #1: Policy
Although it has been said many times, many ways (holiday season pun intended), security starts with security policies. In the absence of explicitly documented security policies nobody can tell you if your data or systems is properly secured.
By definition, security policies describe who can do what (operations, type of access), with various classes of business data and under which conditions. To determine if your data is properly secured, you must test whether your current security implementation correctly enforces your security policies. There are any number of ways to correctly enforce a given policy. Some ways may be more efficient than others, but as long as they correctly enforce security policies the system is properly secured.
Creating and maintaining security policies is ultimately the responsibility of the senior management team. Administrators may participate in parts of the security policy management process, but they should not own or be responsible for driving the process.
Administrators are (or should be) responsible only for effectively enforcing policies associated with any system or data that is stored on — or passes through — the systems for which he or she administers. If you don’t understand these policies, or if they don’t exist, then there is no way you (or anyone else) can know if those business assets are properly secured. Administrators are also responsible for providing feedback to the security policy review process.
You will need a copy of the latest set of policies to understand them and help you participate in the policy review process. Mark up your copy or make notes about changes you recommend for existing policies. Identify policies that require costly processes or procedures to accurately enforce them and provide this information to the policy review team. Be on the lookout for the need for new policies to cover new technology or access methods and bring this to the attention of management.
Must-know #2: Data
You have to know what types of data are stored on or pass through your system. The best and most complete set of security policies in the world won’t do you (or your organization) any good if you aren’t aware of all of the business assets stored or processed on your system. And, of course, if you don’t know where that information is stored or used by your system, you can’t possibly hope to properly protect it.
You must know your data before you can identify the security policies that apply to that data and then determine how to accurately enforce those policies. Just as importantly, you need this information to determine if the security mechanisms you choose accurately and adequately enforce those policies.
It’s Classified
Knowing your data doesn’t necessarily mean that you have to know the details of every field in every database file. The best way to manage your knowledge of data is to classify it. If your security policies don’t explicitly define classes of data, start with at least two: sensitive and non-sensitive. You may also want to classify data based on which business roles own or need access to that data. For example, engineering-sensitive, sales-sensitive, and accounting-sensitive. But when in doubt, just get started using sensitive and non-sensitive. You can always refine your classifications later if needed.
How to Classify
To classify data, for each file or other object on your system that contains data, determine if any of that data is sensitive. For a start, assume that the classification of the entire file is the same as the highest level of classification of any individual column in file. For example, a customer database file may contain social security numbers. You don’t need to know which column, just that the file contains personally identifiable information that is the target of government privacy regulations.
In some cases, you might be aware that all of the files in specific library, folder, or directory contain sensitive information. As long as you know that those files exist only in that location, you can classify all of them by classifying the library, folder, or directory that contains those files. You want to be as accurate as possible, but if you aren’t quite sure it’s better to over-classify.
Document It
Use a spreadsheet or even a database file to track data classification. To minimize the amount of data that you need to track, use hierarchy. Using the example in the previous paragraph, track the classification at the highest level possible; i.e. the library, folder, or directory level rather than for each specific file.
Do It Now!
You don’t have to classify everything all at once. Create a place to store your data classification information and add to it in the course of your daily work. You will eventually have a complete picture of where the sensitive information is stored on your system. If you wait until you have time to classify the whole system, you’ll never get started.
Must-know #3: People
No. I don’t mean you need to know every single person that uses your system personally. But you do need to know the people that use your system based on their role in the organization. In effect, just as you need to classify data based on whether or not it is security sensitive, you also need to classify people that use your system based on their role in the business.
Security policies are developed based on roles in an organization because the people performing in a business role change much more often than the roles they perform.
People are the third leg in the access control triumvirate along with policies and data. If you don’t understand the roles people play in your organization, you won’t know which security policies do or do not apply to them. If you don’t know which security policies apply to an individual, you won’t know how or whether to control their access to sensitive data.
Roles & User Groups
I think user groups are the best way to manage information about people and the roles they play within an organization. If you haven’t already, create a group for each role you identify. Make people a member of each group/role that they have in your organization. Don’t worry about being super precise about these roles to start with. You can always create new roles/groups and change people’s membership in these roles. As you go about your daily work, add the userIDs for people to the group(s) that represents the role(s) they perform.
These groups may eventually become handy when changing existing access control schemes or implementing entirely new ways to enforce security policies.
Must-know #4: Systems
Your security policies, data, and people knowledge – the access control triumvirate — informs your every decision related to how to use and configure the various security-related mechanisms provided by your system. But if someone asked you if your system security configuration had changed, would you be able to provide a definitive answer?
Many administrators would have to equivocate and say something like “not that I know of.” Even tougher would be a request to prove that the security configuration of your system is exactly the same today as it was yesterday. Think about that. The effectiveness of the enforcement of your security policies is based how you have configured the various security mechanisms (system level configuration, user attributes and privileges, access control configuration for data and applications, etc.). And yet many of us really have no way of knowing, much less proving, that the configuration of those mechanisms have not been surreptitiously changed without our knowledge.
Knowing how your system is configured — and that it is still configured the way you originally configured it — is necessary to effectively and efficiently manage security. I strongly recommend purchasing a third-party product to accomplish this. Most commercial solutions provide basic functions in modules that must be pieced together into a full-blown application in order to provide the capabilities you really need. But that tends to be more effective than trying to reinvent the wheel yourself.
Look for something that can be scheduled to run automatically and alerts you only if it identifies differences in your security configuration. You don’t want to have to remember to run the utility because you won’t know about potentially significant changes until the next time you decide to run the application. And you don’t want to have to open a report only to discover that no changes were found.
Must-know #5: Events
No system can be made perfectly secure. The more time a potential intruder has to carry on an attack before someone notices and takes additional measures to thwart the attack, the more likely the attack will be successful, and the less likely you are to know that one even occurred.
This means that you have to know which security-related events may indicate that an attack has occurred or is in process. Network administrators have used tools to notify them of specific types of events for a relatively long time. Many system administrators, however, don’t use similar capabilities on their systems.
You Need an SIEM Product
To be fair, while the facilities for tracking security-relevant event information have long been available for most systems, the analysis is a bear. Automated analysis of event data has been available only through third-party products. These products are often referred to as Security Information and Event Management (SIEM) products.
SIEM products are necessary for knowing the events that occur on your system. (No, I don’t have any financial interest in SEIM products.)
There is so much data that must be analyzed in order to spot the information that may indicate a potential attack, it just isn’t feasible for anyone to manually analyze that much data, especially on a continuous basis.
You really do need a product that automates the analysis and alerts you only when it finds something that needs further investigation. The best of these tools will minimize the number of false positives that send you off investigating events that do not prove to be nefarious.
Summary
As they say, a journey of a thousand miles starts with the first step.
Having a good handle on these five categories of must-know information will give you maximum control over your system security. It will prevent a lot of the anxiety caused by any proposed change in the enforcement of your security policies. It also protects against needless exposures like the facilities engineers being able to copy to contents of the customer list file.
I strongly recommend you get started gathering and tracking the information for each of these categories. Make it your professional New Year’s resolution.
