Skip to main content

Developing Internal Threat Intelligence - practical ways to get smarter about how you secure your environment

To those in the US - Happy Independence Day! So today's topic is on some of the starting points of building a Threat Intelligence function for your internal Security team.  First a couple words on what this is, and is not about.

Often in the work I do, people ask "So do I need Threat Intel? or Do I need to spend $$ on XYZ corp's threat intel feed/software/etc."

Every organization is different, but all organizations can benefit from being aware of threats.  That does not directly translate to a product though.  While some more mature organizations or environments with and extensive Security Operations Center can probably leverage an external threat feed, you will probably get more direct value from looking for anomalies, trends, and other internal indicators of 'evil'.

Here is an article by Digital Guardian that give some very good starting examples, about mining your own internal DNS for potential issues.

https://digitalguardian.com/blog/know-your-network-first-dns-and-power-feature-classification

This is a great place to start, but may even be advanced for some sites.

Some additional starting points to consider:

  • Hardware Inventory - this can be tied to a CMDB or other tool, or can be a simple spreadsheet (or preferably an automated system tied to DHCP, NAC, and 802.1X).  You should watch this for any unknown systems that are placed on the network, failed authentication (NAC/802.1X)

  • Abnormal VPN activity. Depending on the type of environment you have, the nature of your remote workers, and your infrastructure, this may be easy to do, or it may not be easy to identify the anomalies.  Often an attacker can leverage credentials they have compromised to attempt to access the VPN or other remote access systems (OWA, etc.).  This authentication succeeds, because they have the credentials and at this point there is no indication the account is compromised.  If you monitor for multiple concurrent logins, you may be able to catch this type of activity.

  • Changes to local system.  This requires either local logs (that you trust), an additional host based agent, or scripts run on systems on a periodic basis looking for any unexpected changes.  Tools such as Qualys, Rapid7, and Nessus can often be configured to look for these when they do an authenticated scan.

  • Abnormal amount of network traffic.  If you have a good baseline of what normal traffic behavior looks like, you can monitor for activity that is above a threshold that you configure.  This may be a way to detect large file transmission, P2P file sharing, or other possible data transmission activity.

  • Attempts to use a standard user account to authenticate to Domain Controllers, network infrastructure, or other critical systems.  Also if an account is suddenly authenticating to multiple systems in what appears to be an automated or bulk fashion, you may have something worth investigating, or at least a badly configured script or program that you need to speak to the developer about.

  • 'Frequent flyers' - Every company has them, systems or users that continually violate the information security policies, best practices, and common sense, and are continually infected with commodity malware, spyware, or tend to install every software they can double click on.  Aside from the obvious training challenges, these users can present a canary in a coal mine type of scenario for your environment.  Maintain a list of systems and users (both, in the event they end up changing systems or using multiple devices) and when a new threat is identified, run a scan across their systems or use their userID's as a starting point for your SIEM query, grep, etc.
This provides some good starting points for how you can develop your own internal threat intelligence capability.  Not all environments have the bandwidth to do this, but these are often things that can really help you understand the basic behavior of your environment, and when you are responding to an incident, will be some good starting points for you to be able to understand the scope and impact.

EDIT -

Saw a new post by Security Week that is right in line with what I am talking about as well.  Here is the article.

http://www.securityweek.com/using-actionable-intelligence-prevent-future-attacks

A lot of these items go back to having a mature process for dealing with the monitoring, detection, and response.


Comments

Post a Comment

Popular posts from this blog

Requirements for Information Security

If you want to get into Information Security you HAVE to be a/have this skill... Why this is total BS. Almost daily I see someone posting on twitter, trying to be helpful to folks who are looking to get into InfoSec. Often I see "If you want to be in Information Security (Cyber Security) then you HAVE to be a programmer" or "If you want to be successful you have to be a hacker/have a criminal record/have abused systems without permission" etc. While having technical capabilities (such as programming) and having the ability to compromise a system shows a specific skillset neither are required. When talking to people who are interested in Information Security I often refer to it as a cake, there are tons of slices, many flavors, many pieces and parts you can sample, choose to focus on, will be expected to know something about, etc. Incident Response and Forensics (my current focus) is not the only part of Information Security, and certainly not the only part tha
Post a Comment
Read more

Busting the myth of the malicious insider

The Myth of the Insider Threat Too often after the announcement of a new breach, the first reaction from the victim company and the media is "another malicious insider attack".  Case in point, I was catching up on news from various sources and came across the following: http://www.idgconnect.com/abstract/19647/lessons-sage-leak " “We believe there has been some unauthorised access using an internal login to the data of a small number of our UK customers so we are working closely with the authorities to investigate the situation,” the Newcastle, England-headquartered firm said in a statement." Of course an internal login was used to access the data, as part of the attack lifecycle, during your reconnaissance phase you identify accounts to target for possible compromise, based on the access/role of the individual.   Phishing attacks or other simply attacks are often successful in gathering login credentials for individual users, which can then of
Post a Comment
Read more
Weekly recap and why you should be concerned about "attackers" even if you have "nothing to hide" Why you should be aware of, defend against, and prevent attackers... even at home: I often hear from future victims "well I don't have anything to hide/anything of value/why would they target me!?" It's really not about you, usually the attackers aren't looking for your data (if they get it, or have easy access to it, they may try to profit from it, but the people doing the compromising aren't usually the same folks that monetize). What the attackers want are compromised systems they can use to do what they want at scale. So if they can compromise 50 systems, they can send 50X the amount of SPAM... 100 systems, 100X, etc. Some operations get paid based on the number of emails they can send per day. Of course the email will likely not just be SPAM, but may also be malicious (ransomware, etc.). http://thehackernews.com/2017/09/linux-ma
Post a Comment
Read more