When your incident response team gets access to a new log data source, chances are that the events may not only contain an entirely different type of data, but may also be formatted differently than any log data source you already have. Having a data collection and organization standard will ease management and analysis of the data later on. Event attributes must be normalized to a standard format so events from disparate sources have meaning when viewed homogeneously. In addition to normalization, log events must be parsed into fields and labeled in a consistent way across data sources. Ensuring that log data is organized properly is a minimum requirement for efficient log analysis. Without digestible and flexible components, it’s extremely difficult to comprehend a log message. If you have ever paged through screen after screen of log data with no filter, you know what I’m talking about.
Data normalization is the process of transforming a log event into its canonical form, that is, the accepted standard representation of the data required by the organization consuming the data. If the same data can be represented in multiple formats, each possible iteration of the data can be considered a member of an equivalence class. To allow proper sorting, searching, and correlation, all data in the equivalence class must be formatted identically.
As an example, let’s consider timestamps. The C function strftime and its approximately 40 format specifiers give an indication of the potential number of ways a date and time can be represented. The lack of an internationally recognized standard timestamp format, combined with the fact that most programming libraries have adopted strftime’s conversion specifications, means that application developers are free to define timestamps as they see fit. Consuming data that includes timestamps requires recognizing the different formats and normalizing them to an organization’s adopted standard format. Other data contained in logs that may require normalization includes MAC addresses, phone numbers, alarm types, IP addresses, and DNS names. These are examples of equivalence classes, where the same data may be represented by different applications in different formats. In the case of an IP address or a DNS name, the CSIRT may find it beneficial not to normalize the data in-place, but rather to create an additional field, the labels of which are standardized across all data sources where possible.
Read More »
Tags: CSIRT, csirt-playbook, incident response, logging, logs, ncsam-2013, SIEM
DNS is like the town gossip of the network infrastructure. Computers and apps ask DNS questions and you can ask DNS who has been asking to resolve malware domains. When internal trusted systems are using DNS to resolve the names of known malware sites, this can be an Indicator of Compromise and a warning to clean the potentially infected systems and block traffic to the domain.
Blacklisting the known malware domains using local RPZs, firewalls, Cisco IronPort Web Security Appliance (WSA), or Cloud Web Security (CWS) is a great way to add an extra level of security in organizations. But what if you are just getting started in the process of cleaning systems and just need some situational awareness? Or, how can you manually check to see if these devices are working as expected? How can you determine independently of security devices, and at any point in time, that client systems are not reaching out to malicious domains? You can use dig but this post focuses on a Python example. Let’s first take a look at some DNS mechanics.
Read More »
Tags: dns, malware, ncsam-2013, network, security
Cryptography is critical to secure, trustworthy communications. Recent questions within the tech industry have created entirely new discussions about the cryptography underpinning our communications infrastructure. While some in the media have focused on the algorithm chosen for Deterministic Random Bit Generation (DRBG), we’ve seen many more look to have a broader crypto conversation. With this backdrop, I’d like to take the opportunity to talk about how we select algorithms (not just the DRBGs) for our products.
Before we go further, I’ll go ahead and get it out there: we don’t use the DUAL_EC_DRBG in our products. While it is true that some of the libraries in our products can support the DUAL_EC_DRBG, it is not invoked in our products. For our developers, the DRBG selection is driven by an internal standard and delivered to those developers from an internal team of crypto experts through a standard crypto library. The DRBG algorithm choice cannot be changed by the customer. Our Product Security Incident Response Team (PSIRT) confirmed this in a Security Response published on October 16.
Read More »
Tags: cryptography, DUAL_EC_DRBG, security, Security Response
Now when I’m talking about safekeeping a mobile device, I’m not saying don’t use your Kindle by the pool or let your toddler play on the iPad while eating ice cream. These are dangerous things to be doing with a gadget, but today I want to focus more on the data within that device, rather than the device itself.
No matter what you do, your device may be stolen. It only takes a moment of inattention for someone to swipe your phone or tablet. Before that unfortunate event occurs, there are several things that you can do to mitigate the damage that occurs from the loss of a mobile device.
Read More »
Tags: data retention, encryption, mobile, ncsam-2013, passwords, phone, security, Storage, tablet
Now that we’re in the midst of October 2013’s Cyber Security Awareness Month, it’s a good time to think about the connections between security awareness and trust. This discussion centers on three questions:
- How do we trust our computers and devices?
- How do we trust our vendors?
- How do we trust the infrastructure?
We ask these questions mindful that information technology does not stand still and is probably accelerating. Forward progress, however, is unsustainable if we can’t trust the technologies we use. I don’t foresee any scenario where technology progress will come to a halt, but there are many ways it can fly off the rails if we’re not careful. This may sound dire, but I remain an optimist by nature and believe we can confidently move ahead if we take the time to think about security and trust and act on our conclusions. Cyber Security Awareness Month is a good opportunity to think about this, and I have more to say in the video blog post below:
Tags: Cyber Security Awareness Month, ncsam-2013, security awareness, trust