Sender Policy Framework

As I'm sure you know, many organizations face email spoofing/spam/phishing/spear phishing as one of their major infection vectors these days.  Sender Policy Framework (SPF), which is RFC 4408, can help tremendously in combating this infection vector.  SPF uses a DNS TXT record to specify which IP range(s) are permitted to send email as coming from a given domain.  It's implementation is optimal.  SPF's elegance is in its simplicity, and I would encourage organizations to consider implementing it if they haven't already.

To think about it through a concrete example, say I wanted to relay email and spoof the sender such that the email appears to be sent from someguy@example.com. If I'm attempting to relay email from a cable modem dynamic IP address, then I'm probably not a legit mail gateway for example.com.  Implementing SPF instructs your mail server to perform this "reality check" before accepting the email.  Seems straightforward, right?  Exactly.

Taming Your Ingress/Egress Points

Many organizations have legacy ingress/egress points that will route traffic to and from the Internet.  In some cases, these ingress/egress points may have been "forgotten" about and as a result, are not being properly monitored.  A well-run Security Operations Center (SOC)/Incident Response Center (IRC) can be highly effective and can greatly improve the security posture of an organization, but only if all ingress/egress points are well known and properly instrumented.  To think about it another way, it's like trying to defend the network based on data that simply isn't there. Pretty hard to do.

Other Alphabets

Westerners often forget that there are a decent number of alphabets in use that don't use Latin characters.  In 2009, internationalized domain names that use non-Latin characters were approved, allowing for a much broader array of characters from which to build domain names.  The non-Latin characters are translated for our "Latin-only" DNS system using a schema known as "Punycode".  What does this mean for analysts?  There are a lot more domain names in use on our network than we might realize.  Unfortunately, because of this, some of our "Latin-centric" analytical methods may miss certain traffic that we may want to inspect more closely.  It's something to be aware of.  Don't be a "Latin-centric" analyst.  :-)

Window of Opportunity

As I'm sure most of you reading this blog know, drive-by web re-directs are a major malicious code infection vector for organizations these days.  Many proxy vendors continually make a noble effort to stay on top of domains hosting malicious code and push blocks down to their customers' proxy devices.  This is actually highly effective at preventing a large number of malicious code infections in enterprises.  What's interesting analytically though is that there is usually a 24-48 hour window between when a domain begins hosting malicious code and when the proxy vendors are able to push the blocks down to their customers.  That time period is a window of opportunity for the attackers, and it's often enough time to infect countless systems.

So how can we turn this tidbit into an interesting analytical technique?  What about reviewing the list of blocks received from our proxy vendor and searching back a week or two in our proxy log data to see if any systems were infected before the block was pushed down?  Pretty neat if you ask me, and a highly effective way to identify infected systems in the enterprise.

Common Challenges

When I work with Security Operations Center (SOC)/Incident Reponse (IR) clients that are in the SOC/IR building phase, I often see them encountering similar challenges. More often than not, the clients are frustrated and overwhelmed, as they desperately want to do the right thing. The good news, I reassure them, is that all organizations have the same fundamental challenges. I've worked with quite a few different organizations, and there is always a way through the maze. Clients often find it reassuring to know that they are not the only organization with the challenges they see before them. I am more than happy to help them through the fog. In fact, one client recently told me I should write a book about SOC/IR building. Maybe I will one day....

Give and Take

The cyber security community is a community built almost entirely on trust. This is especially true in the Security Operations Center (SOC)/Incident Response (IR) world. Relationships are built over time through a give and take. In other words, an organization should expect to give to the community before expecting to take from the community. At the very least, an organization should attempt to truly understand the community and its nature before attempting to wedge in. It amazes me how many organizations attempt to take from the community with no history of or intention of giving anything back. The SOC/IR community is a close knit one, and this type of behavior is often perceived as untrustworthy and/or exploitative. Needless to say, these types of organizations aren't very successful in making any headway in the community. Perhaps what amazes me even more is how surprised some of these organizations are by the lack of progress, despite being advised to the contrary. I believe the psychological term for this type of behavior is "cognitive dissonance".

Uber Data Source

This afternoon I gave my GFIRST talk entitled "Uber Data Source: Holy Grail or Final Fantasy?". The purpose of the talk was to get people in the audience thinking about the challenges of complex network instrumentation/data collection and data overload confronting many Incident Response Center (IRC)/Security Operations Center (SOC) organizations today. A number of people seemed to agree that the current model of collecting dozens of different formats of data in increasingly larger and larger volumes and varieties can't continue.

The community appears to be receptive to the idea that we need to consider moving towards a consolidated uber data source that allows us to successfully monitor our networks and investigate incidents/events. In addition, there are a number of vendors beginning to move in this direction, which is great to see.

My talk should be posted on the GFIRST conference website (http://www.us-cert.gov/GFIRST) after the conclusion of the conference. I'd be interested in hearing thoughts and opinions regarding both the talk and the concept of the uber data source in general.