Major security solution vendors, government agencies, and even the central IT departments of some very large technology businesses collect and analyze a lot of data about security vulnerabilities, threats, and incidents. The temptation to do so is easy to understand. After all, knowing more about the threat in the environment in which you operate helps to avoid, counteract, and respond to them.
Assembling and maintaining a database of vulnerabilities, threats, and incidents may cause the very resources you wish to protect to be even more exposed to security threats if you aren't careful, though. Ask yourself the following ten questions when considering how to implement and manage a database of information intended for security analysis:
- Does the database design focus on the forms of data most valuable for your analyses? There are a number of reasons that one should be careful about the kind of data one collects in such a database. Too much data makes it more difficult to develop meaningful results by filtering and analyzing. It can also slow the process down significantly. Before anything else, you should determine exactly what data is most important to your threat analysis goals, and focus on collecting only that data so that too broad and poorly defined a data collection policy doesn't make the whole plan counterproductive.
- Does it duplicate sensitive data that doesn't need to be in the database? Sensitive data — not just obviously sensitive data of the sort that is normally managed by your organization, but also any data generated by your data collection process that could prove damaging in the wrong hands — should not be unnecessarily duplicated. Duplicating sensitive data duplicates the opportunities for unauthorized parties to access it.
- Are there any potential conflicts between your threat data collection policies and real-world security policies? If security policies are changed to allow threat data collection where it would otherwise conflict with those policies, and even if policies need not be changed, there is always the possibility that the collection process itself will create additional vulnerabilities in your organization's operations. Examine your data collection plans for signs of vulnerabilities that may be created when those plans are implemented. Consider not only whether data collection procedures should be changed or scrapped if new vulnerabilities may arise or if existing security policies may need to be weakened to allow for data collection, but also whether the fact that some policies may not need changing to allow data collection is in fact a sign the security policies needed strengthening in the first place.
- Are there measures in place to ensure that those with access do not abuse it? Obviously, someone needs access to the threat database, and someone must be tasked with building and maintaining the database. What happens if those people abuse that access, either through mistakes or malicious intent? To the extent possible, such people should usually be accountable to someone, and their activities should be auditable — preferably without exposing sensitive data to unauthorized auditors, of course. If irregularities are detected, the people responsible for them should have to account for them.
- How is the database itself secured from unauthorized access?
It should go without saying that technical solutions for the security of the database should be in place from day one. If your threat database is being assembled from data to which you have access, or means of gaining access, that others do not enjoy, a poorly secured database can lead to people who are not authorized to interact with the database itself gaining access to that data. Perhaps worse (depending on what data the database will actually store), unauthorized people may be able to change the data, affecting the outcome of your later analyses so that they become less effective in your attempts to improve security policies and respond to threats.It's also important to keep in mind that you should not simply try to keep everything secret without having a good reason to do so. Trying too hard to protect nonsensitive data from outside access divert resources from other, more important security priorities, and the benefits of opening up as much data as reasonably possible to greater availability so that people outside the core threat database management and analysis teams can make use of it as well may provide additional security benefits, thanks to the principle of security through visibility. Publishing nonsensitive data for wider circulation can prove quite beneficial, as long as you're sure the data is nonsensitive, and that those who have been granted such access to that published data do not have access to other, more sensitive data as a result.
- Is the authorization list for access to the database well-planned to maximize security of the data inside it? If too many people have access, or if the wrong people have access to it, the threat database and the data it contains becomes more vulnerable to compromise. Conflicts of interest, a lack of an actual need to access the threat database directly, an absence of resources necessary to ensure access is secure, and other, similarly problematic conditions should disqualify someone for authorization to access the database. Furthermore, the criteria for access should be maintained rigorously to minimize access to the threat database, with clear rules for who may be granted authorization. Use a default-deny policy for authorization; additional personnel should only be granted authorization if it is really needed, and if it doesn't compromise the security of the database itself, the data it is designed to store, or any other operations the data addresses.
- How well trained are people with authorized access to the database to avoid mistakes that can compromise its security? Authorization to access the threat database is not enough. You should not only consider whether people need access to the data to do their jobs and whether their intentions are pure; you should also ensure that they know enough about security policies and dangers that they will not inadvertently introduce greater vulnerability to the system. Where necessary, ensure that people who are granted access are properly trained to ensure they understand the consequences of their actions and will not accidentally compromise the database's security or give others the information they need to do so.
- Will policies for managing the database include log auditing that can differentiate between authorized and unauthorized changes? The answer to this question should always be "yes", unless you have a very specific, well considered security reason to do otherwise.
- Can the design of the threat database system be simplified without losing needed capabilities?
Antoine de Saint-Exupery said "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." Albert Einstein said "Everything should be made as simple as possible, but not simpler." Charles Anthony Richard Hoare said "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." All three of them are right, especially when it comes to security.Simplicity is the ally of security. Complexity is its enemy. To maximize security, always consider whether your new security project's design can be simplified, preferably to the point of eliminating the project altogether if the expected security benefits are outweighed by the potential security vulnerabilities that may be introduced.
- What will you do if the database itself becomes a security liability? If the threat database itself presents a new vulnerability, as I just pointed out when discussing simplicity of design, you should of course not implement it in the first place. If it does not present a new vulnerability overall, that doesn't necessarily mean this will always be the case. Be prepared to clean up after yourself fully if such a dire circumstance arises.
Aggregating and analyzing public data is of course not really subject to all of these points, but to the extent that less public data falls within the bounds of your threat database plans, ensure you have good answers each and every question in the above list. This is, sadly, most relevant to government data collection and analysis programs, where institutional incompetence and widespread, low-grade corruption may prove unavoidable — if not now, then perhaps after the next election, or once the budgeting authority for the project gets shuffled around a bit.
Corporate and emergency response team projects shouldn't consider themselves exempt from the concerns raised here just because they may not be subject to as much governmental involvement in their affairs, though. Any time a lot of security related data is collected in one place for analysis, the consequences of doing so must be analyzed first to ensure everyone is sufficiently protected from the potential for abuse, compromise, or negligence.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.