I have written a lot about this topic over the years and was recently reviewing my Compliance Is Not Security – Busted! post and the comments that came in regarding it.
A theme of a number of the comments was that compliance does not equal security. DUH! I have never once said or even implied that compliance equaled security as – yes, here it comes – security is not perfect! However, if you are complying with any security program/framework such as the PCI DSS, ISO 27K, etc., then you are likely more secure than those who are not.
Security technology such as firewalls, routers, servers, applications, etc. can all be set up with rules that are complied with 100% of the time, day in and day out, no exceptions. The problem comes down to people who are fallible. Their compliance is never 100% and you are probably lucky to have anyone above 90%, no matter how much security awareness training you do. As a result, in organizations that are truly complying with the PCI standards, this is where the security breach starts, with people for one reason or another.
No, I am not necessarily talking about social engineering, although social engineering is growing because of the fact that organizations have invested a lot in security technologies yet people are fallible. People can be the root cause because of any or all of the following.
- How dare you do that to me! This is the most obvious of the people issues that comes to mind. Face it, when backed into a corner, people lash out just like a trapped animal. The supposedly wronged party wants their proverbial “pound of flesh.” They get that pound of flesh by hurting the organization that has just hurt them. This can be as minimal as taking office supplies to downloading databases to a USB drive as they empty their desk. Obviously, a database, network or system administrator’s access is much different than a clerk’s. However, if your security is minimal on the inside as it is in most organizations, the clerk may actually have better access than the administrators when it comes to sensitive information. Such a situation may not be the fault of the administrators, that old version of POS or ERP may not have the ability to be more granular regarding access to information.
- Over inundated with alerts and cannot identify real alerts from false positives. This typically occurs when an automated tool is implemented but never tuned to the organization’s environment. In this sort of an environment, finding real alerts can be like finding a needle in a haystack when there are thousands of alerts an hour scrolling by on the screen. This usually makes management wonder why the tool was needed in the first place.
- Saw an alert and ignored it. We see this most often coupled with the aforementioned inundation issue. The other most common version of this issue is with internally used SSL certificates that were generated incorrectly or use a default certificate supplied by the application. Users then see the “There is a problem with this Website’s security certificate” or similar error message in their browser whenever these flawed certificates are encountered and become conditioned to ignore the error message. Over time, they become conditioned to ignore all of these sorts of messages, including those for malware infected Web sites and, surprise, you have been compromised. I have lost count how many people have said to me, “We just ignore those alerts because we know they are false positives.”
- Saw the alert but got side tracked and never came back to it. This is a problem we see all of the time. For example, the person that monitors the network is also the person that manages the network and configures the network. An alert comes in and the person begins a root cause analysis (RCA) only to get pulled away because a remote facility is offline. The offline issue gets resolved, but other issues come up as well as meetings and telephone calls and the person never gets back to the RCA for the alert because there is no “tickler” to remind them to go back and complete the RCA. In the meantime, the attacker has gained their beachhead and is probing the network for whatever value it may contain.
- Just did not put together all of the pieces to know they were compromised. Like the reasons 9/11 occurred, most organizations do not correlate all of the potential incidents occurring in their networks and therefore do not understand that there is an active effort to compromise their network or that they have already been compromised until well after the incident has caused damage. The reason this is important is that once an attacker is inside your organization’s security perimeter, it is typically game over because there are few controls to prevent access and identify that data is being taken.
If you have read the Verizon Business Services Data Breach Investigations Reports (DBIR) over the years you know how the bulk of attacks get inside, they are the result of people. For the last two years, the DBIR has used the VERIS Event Threat Grid to show how breaches occur. Across the top of the grid are the categories; Malware, Hacking, Social, Misuse, Physical, Error and Environmental. The Social, Misuse and Error categories imply mistakes or deliberate acts of people. If you read the definitions on the VERIS Web site, Malware is also very people centric as is hacking. Surprisingly to some will be that the Physical and Environmental categories also have a good number of people errors. Based on just a quick read, it looks to be that about 60% to even 70% of all of the incidents categorized by VERIS has some form of people error component.
Since we are not going to get rid of people in our organizations any time soon, what are you to do?
- Admit that people are the problem and focus your security measures accordingly. Every 12 step program says the first step is to admit the problem which, in this case, is that people are fallible. As a result, we need to construct our security measures such that this fallibility is minimized as much as possible. One of the best solutions is to integrate alerts into your help desk or change management system so that a ticket is generated. Those tickets need to have an escalation process behind them so that if they are not investigated within a period of time, they are bumped up to the next higher rung of management and that escalation continues until the tickets are finally addressed. This way there is visibility for the alerts should they slip through the cracks. As a side benefit of this approach, you gain statistics to reinforce why you need more staff and/or more/better tools.
- Strengthen your internal security measures. As things stand, once inside most organization’s security perimeter, there is very little that stands in the way of an experienced attacker getting the data they desire. Regardless of whether it is an insider attack or an attacker has managed to get inside, there is already justification for organizations to beef up their internal security measures. To address this problem, I would recommend the security architectures as documented in my Fort Knox approach, Forrester’s Zero Trust Model or McGladrey’s Ultra Secure Network. But most organizations do not have the infrastructure architecture, the application architecture or even the will to take such approaches. But that does not excuse an organization from just saying they cannot do anything. If anything, most organizations could vastly improve the monitoring they do on their internal networks. Monitoring needs to be coupled with reducing the total number of ports that are open between network segments. Most internal networks do a terrible job of this because of a variety of factors including applications people that cannot tell what ports need to be open to avoiding operational issues by just leaving things open. Another area of improvement is reviewing user access rights on all systems and applications, not just those in-scope for PCI compliance.
- Constantly tune your alerting system(s). Just as attack methods are not static, neither are networks, systems and applications. Changes are occurring all of the time in an organization’s IT environment, yet if you ask the people running the SIEM about changes, nine times out of ten, nothing seems to be changing other than requests to look for a new signature or anomaly. There is a belief in the SIEM user community that a SIEM’s update process is making the necessary changes in the policies that ship with the SIEM. To a certain extent SIEM solutions are similar to anti-virus and malware solutions. However, because a SIEM monitors log data and the log data provided varies greatly from organization to organization, each organization needs to periodically review and adjust their alerting criteria to make sure that it reflects the organization’s operating environment and not just some template from the SIEM vendor. If an organization is not reviewing its SIEM alerting rules based on the changes made, at least quarterly, then it is highly likely that the SIEM is not alerting properly.
- Establish separate consoles from your SIEM for network, system, security and application administrators. What a network administrator is looking for is vastly different from what an application administrator is looking for and what any particular group might be looking for to generate an alert. As a result, to have only one console is really silly and non-productive. Yet time and again, we see SIEM implementations with just that, one console and everyone being driven by email or SMS alerts. The people alerted then have to get to the SIEM to find out what exactly triggered the alert and then determine what to do about it. Having your own console view simplified things by only listing that viewer’s alerts and no one else’s alerts. This allows people to focus on their problems and not the whole organizations problems. The idea behind the single console is that if everyone knows what is going on overall, then correlation would occur because everyone sees everything. While you would think that would be the case, in reality, people just want to fix their problem and move on, not the entire organization. Which leads to my last point.
- Watch the overall alerting picture so that correlations can be made. According to most sources, today’s attacks are becoming more sophisticated and multi-pronged in their approach. For example, while most DDoS attacks are just to be a pain in the posterior to the target and disrupt access to the target’s Web site, there are those DDoS attacks that are used as cover so that people inside are blinded to the real attack(s). Whether or not the DDoS was a decoy depends on what other events or incidents occurred during the DDoS attack, if your alerting system did its work. Higher end SIEM solutions can provide basic correlation rules, but most SIEM solutions require the end user to develop those correlation rules. It is these correlation rules that help organization identify these more sophisticated attacks. That said, these correlation rules do not have to be very sophisticated. For example, during a DDoS attack, you really only need to look for malware attacks, failed authentication attempts and other anomalies that would be likely indicators of the DDoS attack being used to mask the real attack.
Is all of this going to address your security issues? Sorry, not a chance. None of the above stops all breaches, it merely minimizes the possibility that a breach goes on for months or years. Hopefully it minimizes a breach down to weeks, days, maybe even hours in some cases but it will never totally eliminate them. Security is not perfect.
There is a side benefit to all of this and that is it will assist you in doing RCA. RCA is very effective in getting rid of those nagging operation issues that occur from time to time and mess up the delivery of your organization’s goods and services. All of the information you collect for security purposes can also be used to find the needle in the haystack that is causing a database to corrupt, a network connection to drop or a server to fail because now you have information as to what was going on that led up to the problem.
The reason an organization is not secure is that there are so many areas of improvement needed that the full control triad is no longer functioning and holes exist that will allow an attacker to operate without the knowledge of the organization. Until the controls are implemented and operating properly, it will be impossible to determine if they are secure or not. The recommendations I have made will hopefully give you a better picture of what you face and reacting to issues that need attention before your organization is the next one to be breached.
