Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.
Security Community Blog

Epidigitalogy: Digital Disease Control (Part IV)

Leveraging Waiting Room Time
Created: 22 Aug 2014 • Updated: 28 Aug 2014
EfrainO's picture
+1 1 Vote
Login to vote

Leveraging Waiting Room Time
     Organizations can continue to rely solely on their security vendors to provide the miracle drug or antidote for the digital disease pathogen, or they can take more of a hands-on surveying approach to improve security. Relying on the security vendor is the traditional practice which is normally followed by applying pressure on the security vendor to deliver the miracle drug or antidote quickly. This time spent waiting allows the digital disease pathogens to possibly mutate and spread further in the environment. Another approach taken by organizations is the installation of many different security technologies with all the bells and whistles activated in hopes of detecting and preventing the next threat. Unfortunately, enabling all the prevention features of a security product or collection of security products may present an unwanted side effect: with prevention enabled at a very aggressive level, the possibility of false positives increases. What if we leveraged the extra protection technologies in logging mode initially and made subsequent policy changes based on statistically significant observations?

Here is an example of a SIR surveying tool:


Illustration 4. Susceptibility, Infection and Recovery Timeline
           Illustration 4 shows a SIR timeline borrowed from epidemiology, which is normally applied to tracking Susceptibility, Infection, and Recovery (SIR) of human beings during an outbreak investigation. In this epidigitalogy SIR graph sample, the x-axis represents 30 days of time. The y-axis represents the individual digital hosts in the environment. As time progresses across the x-axis, a red circle indicates when an infection has been reported. The length of the line indicates the duration of infection with the red line termination indicating the resolution of the infection. Any hosts which are repeatedly infected will show up easily to the epidigitalogist. A pattern of reoccurrence of events is indicative of an underlying issue on the host that needs further investigation. The illustration also identifies the "expiration" of a host with a black dot and length of time since commencement of expiration. In the case of digital hosts, a black dot with a black line indicates both the start of expiration and the length of time since it last reported into the central reporting system. If a host reports digital disease indicators were detected and repeatedly cleaned, this graph will illustrate a recurrence that may mask a deeper digital disease pathogen. For example, a host with a downloader may not have the downloader identified directly, but the repeated downloading and cleaning of secondary files may be a tell-tale sign of a deeper issue. By observing this type of repeated action on the graph, a host may be placed under watch for further analysis or continued study.
     One of the software tools the Center for Disease Control and Prevention Epidemic Intelligence Services (CDC EIS) personnel use in their investigation processes is called EpiInfo. During the development of this epidigitalogy idea, I tested EpiInfo with Endpoint Security logs to determine if the analysis from EpiInfo added value to an investigation of a digital host population. What I discovered was that the statistical models used by epidemiologists for frequency count, 2x2 analysis, and proactive trending for diseases in the human population is applicable to digital hosts.
Here is an example of using the CDC’s EpiInfo to get to the “a-ha” moment that connects the tools used by epidemiologists to epidigitalogists. We first perform a basic frequency distribution count across machines, applications or non-malicious file alerts in the environment. If we take a look at the frequency count of executable violations of application access rules, we obtain a list of the files with the most violations of the policy. By performing an MxN, 2x2 analysis in EpiInfo, we quickly see that copycode.exe is violating the USB write policy. We can follow this 2x2 table with a list of all machines containing copycode.exe. We can then look at all activity for the systems that had copycode.exe present.


Illustration 5. EpiInfo MxN, 2x2 Report Generation Widget
       In these 2x2 tables, epidigitalogists look at what the hosts were exposed to and the corresponding health outcome. This allows epidigitalogists to quantify the association between exposure to a digital disease pathogen and the resulting outcome. When this type of report is run, the epidigitalogist can begin to make inferences from the data. In the case of this 2x2 it appears that copycode.exe is triggering the most USB write block events. It is important to point out that these are not virus alerts, but simple policy violations that may be indicative of digital disease presence. It's completely possible that this is an internal application and an authorized user, but it may also be a data leak. We cannot know for sure if this is intentional, unintentional or malicious in nature. An epidigitalogist that knows their environment will be able to better filter out the noise and get to the rare-but-deadly digital diseases. This report will (at a minimum) get an epidigitalogist on the path to investigate further using the existing logs, and if further analysis of logs contain more indicators, more hands-on analysis of the hosts may be necessary.

Illustration 6. EpiInfo MxN, 2x2 Report Results
     Illustration 6 shows the detected processes by rule violation. By looking closely at the Rule_Name count, it is easy to see that 199 USB blocks were triggered by copycode.exe. The other entries are more easily filtered out based on knowledge of the environment and the known good status of setup.exe and chrome.exe.
What if, instead of encasing our hosts with inconvenient security bubbles, we were to continuously monitor them and survey them in order to respond so quickly to the initial disease pathogens that we can remove the disease before it makes a strong foothold? By taking this continuous monitoring and surveying approach, we strike a balance between early detection and response, and minimizing of false positives. Do we really wish to continue to wait in the information security emergency room for our next patient? Do we wish to wait for the security vendor to deliver the vaccine or cure for our digital disease symptoms? Or do we start taking some proactive action of our own? Should we start doing the equivalent of epidemiological investigations? Should we start incorporating a daily survey into our regimen? Should we educate end users on the healthy habits of computing? As the equivalent of washing their hands as a preventive health measure, let's make sure the hosts do not go into the dirty water. But if they must enter the dirty water, let’s ensure they go with adequate protection or at least have someone ready to help them out of the water and decontaminate them quickly.

Trust In Our Digital Cities
     During Dr. Snow’s time the general belief was that cities were unhealthy, and humanity was not destined to live there due to the prevalence of diseases. Epidemics were presented as evidence of the unnatural state of humans in cities and the resulting hardships encountered there. If you were to ask a mid-19th century Londoner what they thought of the future of cities, they would probably tell you that it was a passing phase and that disease will send people back to the country side. If you asked the average person today what they thought of their digital existence online, they would probably say they don't trust it, and that the rampant diseases online make it a place humanity will not be able to fully integrate into their lives. Some people have already retreated to the digital country side or avoided the digital as much as possible, rather than fully integrate into the network. This lack of trust in ecommerce and online banking is not that different from mid-19th century Londoners’ view of the viability of cities and whether people should really be there.  It is up to us to start treating the threats for what they really are: digital diseases. Once we understand digital diseases better, we can learn to adapt our hosts and environments to withstand them.
To be successful, like Dr. Snow, we must know our digital community. We must know our network and know our digital citizens. By knowing our "normal" boundaries, we can detect the abnormal. We can no longer simply sit back and wait for antivirus logs. Looking only at antivirus logs is like only looking at death certificates. Look at other data: login internals, patching cycles, install instances, network traffic, etc.  The better we understand our community the better we can take care of it.


Previous post Part III Following in Dr. John Snow's Footsteps
Next post Epidigitalogy Survey Study Types