Rapid7 Blog


SIEM Market Evolution And The Future of SIEM Tools

There’s a lot to be learned by watching a market like SIEM adapt as technology evolves, both for the attackers and the analysis.…

There’s a lot to be learned by watching a market like SIEM adapt as technology evolves, both for the attackers and the analysis.

InsightIDR Now Supports Multi-Factor Auth and Data Archiving

InsightIDR is now part of the Rapid7 platform. Learn more about our platform vision and how it enables you to have the SIEM solution you've always wanted.…

InsightIDR is now part of the Rapid7 platform. Learn more about our platform vision and how it enables you to have the SIEM solution you've always wanted.

Want to try InsightIDR in Your Environment? Free Trial Now Available

InsightIDR, our SIEM powered by user behavior analytics, is now available to try in your environment. This post shares how it can help your security team.…

InsightIDR, our SIEM powered by user behavior analytics, is now available to try in your environment. This post shares how it can help your security team.

PCI DSS Dashboards in InsightIDR: New Pre-Built Cards

No matter how much you mature your security program and reduce the risk of a breach, your life includes the need to report across the company, and periodically, to auditors. We want to make that part as easy as possible. We built InsightIDR as a…

No matter how much you mature your security program and reduce the risk of a breach, your life includes the need to report across the company, and periodically, to auditors. We want to make that part as easy as possible. We built InsightIDR as a SaaS SIEM on top of our proven User Behavior Analytics (UBA) technology to address your incident detection and response needs. Late last year, we added the ability to create custom dashboards and reports through the Card Library and the Log Entry Query Language (LEQL). Now, we’ve added seven pre-built cards that align directly to PCI DSS v3.2, to help you find important behaviors and communicate it out across the company, the board, and external auditors. Let’s walk through a quick overview of the seven cards and how it ties to the requirements in PCI DSS v3.2. 1.3.5: Denied Connection Attempts PCI Requirement 1 covers installing and maintaining a firewall configuration to protect cardholder data. InsightIDR can easily ingest and visualize all of your security data, and with our cloud architecture, you don’t need to worry about housing and maintaining a datastore, even as your organization grows with global offices or acquisition. The above card is a standard, important use-case to identify anomalies and trends from your firewall data. In this case, the card runs the query, “where(connection_status=DENY) groupby(source_address)” over your firewall log data. 4.1c: Potential Insecure Connections It’s important to identify traffic with destination to port 80, or the use of outdated SSL/TLS, especially for traffic around the CDE. This can help identify misconfigurations and ensure per Req 4, transmission of cardholder data is encrypted. As with all cards, you can click on the top right gear to pivot into log search, for more context around any particular IP address. 7.1.2b & 8.1.4: Users Accessing the CDE Identifying which users have accessed the PCI environment is important, as is digging a layer deeper. When did they last access the CDE, and from what asset? This is all important context used when identifying the use of compromised credentials. If the creds for Emanuel Osborne, who has access to the cardholder environment, are used to log in from a completely new asset, should your team be worried? We think so—and that’s why our pre-built detections will automatically alert you. From this card, you can pivot to log search to identify the date of last access. On the top global search, any name can be entered to show you all of the assets where those credentials have been used (new asset logon is tracked as a notable behavior). 8.1.1: Shared/Linked Accounts in the CDE Credentials being shared by multiple people is dangerous, as it makes it much more difficult to retrace behavior and identify compromise. This card draws from asset authentication data to identify when the source account is not the destination (where(sourceaccount != destinationaccount) groupby(destinationaccount)), so your team can proactively reduce this risk, especially for the critical CDE. 8.1.3a: Monitor Deactivated Accounts Similar to the above, it’s important to know when deactivated accounts are re-enabled and used to access the CDE—many InsightIDR alerts focus on this attack vector as we’ve found that disabled and service accounts are common targets for lateral movement. Related: See how InsightIDR allows you to detect and investigate lateral movement. This card highlights users with accounts deactivated over the last 30 days. 10.2.4: Highlight Relevant Log Events 10.2.5a: Track & Monitor Authentications Ah, the beefy Requirement 10: track and monitor access to network resources and cardholder data. This is where InsightIDR shines. All of your disparate log data is centralized (Req. 10.2) to detect malicious behavior across the attack chain (Req. 10.6). With the standard subscription, the data is stored and fully searchable for 13 months (Req. 10.7). These two cards highlight failed and successful authentications, so you can quickly spot anomalies and dig deeper. If you’ve been able to use InsightIDR for a few months, you already know that we’ll surface important authentication events to you in the form of alerts and notable events. These cards will ease sharing your findings and current posture outside the team. For a comprehensive list of how InsightIDR can help you maintain PCI Compliance, check out our PCI DSS v3.2 guide here. If you don’t have InsightIDR, check out our interactive product tour to see how it can help unify your data, detect across the attack chain, and prioritize your search with security analytics.

More Answers, Less Query Language: Bringing Visual Search to InsightIDR

Sitting down with your data lake and asking it questions has never been easy. In the infosec world, there are additional layers of complexity. Users are bouncing between assets, services, and geographical locations, with each monitoring silo producing its own log files and slivers of…

Sitting down with your data lake and asking it questions has never been easy. In the infosec world, there are additional layers of complexity. Users are bouncing between assets, services, and geographical locations, with each monitoring silo producing its own log files and slivers of the complete picture. From a human perspective, distilling this data requires two unique skillsets: Incident Response: Is this anomalous activity a false positive, a misconfiguration, or true malicious behavior? Data Manipulation: What search query should I construct to get what I need? Do I need to build a custom rule for this, or report on this statistic? We’ve built InsightIDR with the goal of reducing friction and complexity on both of these fronts. On the incident response side, you’re armed with a dossier of user behavior analytics across network, endpoint, and cloud services to make faster, informed decisions. You can now enjoy Visual Search, which aims to lower the level of complexity associated with writing queries and making sense of your wealth of log data. Visual Search was first released in InsightOps, our solution for IT infrastructure monitoring and troubleshooting. It’s had a great reception, and we’re proud that it’s now a shared service also available in InsightIDR. Visual Search identifies anomalies, allows for flexible drill-downs, and helps you build queries without using the Log Entries Query Language (LEQL). Your First Visual Search In InsightIDR, start by heading to Log Search. You’ll notice that we’ve refreshed the look and feel—we’re continuously improving the speed and responsiveness of the search technology. A breakdown of the updated interface: Activate Visual Search by selecting it under the Mode dropdown. At this point, three cards will auto-populate, proactively identifying anomalies from your data. For each data set, we brainstormed with security teams, including our own, to map out interesting starter queries. You can click on the gear to edit, copy, or remove the card. This is the same architecture as the cards in Dashboards, so the suggested queries can improve your LEQL skills and help you see your data differently. From here, you can click into any of the bars or data points on the card to drill further. For example, for the “Group by destination_port” card, we can click on the 5666 bar. It automatically performs the search query, where(destination_port=5666). Visual Search is a great first step in highlighting “where to look”. As each data set is enriched with user and location data, this feature really highlights the user behavior analytics core in InsightIDR. These cards wouldn’t be possible to populate from the raw log data alone. By proactively identifying anomalies tailored to each data set, and guiding you towards LEQL search strings, you can find answers while gaining skill along the way. If you don’t have InsightIDR, but would like to know how customers are using the combined UBA+SIEM+EDR capabilities, head over to our interactive product tour to explore top use-cases.

Wanna see WannaCry vulns in Splunk?

Do you want to see your WannaCry vulns all in one dashboard in Splunk? We've got you covered. Before you start, make sure you have these two apps installed in your Splunk App: Rapid7 Nexpose Technology Add-On for Splunk Rapid7 Nexpose for Splunk Steps 1.…

Do you want to see your WannaCry vulns all in one dashboard in Splunk? We've got you covered. Before you start, make sure you have these two apps installed in your Splunk App: Rapid7 Nexpose Technology Add-On for Splunk Rapid7 Nexpose for Splunk Steps 1. Follow the directions in this blog post to create a custom scan template. 2. Scan your targets with the scan template as shown in the blog above. 3. Create a Dynamic Asset Group (DAG) containing the 8 CVEs (as shown in the blog post). In this example I called the Asset Group “Wannacry Assets.” 4. Create a Site in InsightVM or Nexpose, for Assets use Asset Groups and select the DAG you just made. 5. Let your InsightVM or Nexpose to Splunk sync occur (this happens at 4am by default). 6. Use Filter on Rapid7 Dashboard to pick that site! In this example I called the Site: Wannacry. And there you have it: a dashboard of your WannaCry vulns in Splunk, as found by Nexpose or InsightVM. You can also export the dashboard as a PDF report if you would like to share it. Not a customer of ours? Download a free trial of InsightVM to get started. If you're a Splunk customer concerned about security, we can help. InsightIDR, our incident detection and response solution, uses your existing data sources—including Splunk—to identify stealthy attacks and prioritize risk across your environment. Discover how InsightIDR can help your team solve multiple security use cases without worrying about rising data costs or maintaining custom rules and queries. Take an interactive product tour.

The Shadow Brokers Leaked Exploits Explained

The Rapid7 team has been busy evaluating the threats posed by last Friday's Shadow Broker exploit and tool release and answering questions from colleagues, customers, and family members about the release. We know that many people have questions about exactly what was released, the threat…

The Rapid7 team has been busy evaluating the threats posed by last Friday's Shadow Broker exploit and tool release and answering questions from colleagues, customers, and family members about the release. We know that many people have questions about exactly what was released, the threat it poses, and how to respond, so we have decided to compile a list of frequently asked questions. What's the story? On Friday, April 15, a hacking group known as the “Shadow Brokers” released a trove of alleged NSA data, detailing exploits and vulnerabilities in a range of technologies. The data includes information on multiple Windows exploits, a framework called Fuzzbunch for loading the exploit binaries onto systems, and a variety of post-exploitation tools. This was understandably a cause for concern, but fortunately, none of the exploits were zero days. Many targeted older systems and the vulnerabilities they exploited were well-known, and four of the exploits targeted vulnerabilities that were patched last month. Who are these shady characters? The Shadow Brokers are a group that emerged in August of 2016, claiming to have information on tools used by a threat group known as Equation Group. The initial information that was leaked by the Shadow Brokers involved firewall implants and exploitation scripts targeting vendors such as Cisco, Juniper, and Topsec, which were confirmed to be real and subsequently patched by the various vendors. Shadow Brokers also claimed to have access to a larger trove of information that they would sell for 1 million bitcoins, and later lowered the amount to 10,000 bitcoins, which could be crowdfunded so that the tools would be released to the public, rather than just to the highest bidder. The Shadow Brokers have popped up from time to time over the past 9 months leaking additional information, including IP addresses used by the Equation Group and additional tools. Last week, having failed to make their price, they released the password for the encrypted archive, and the security community went into a frenzy of salivation and speculation as it raced to unpack the secrets held in the vault. The April 15th release seems to be the culmination of the Shadow Brokers' activity; however, it is possible that there is still additional information about the Equation Group that they have not yet released to the public. Should you be worried? A trove of nation state-level exploits being released for anyone to use is certainly not a good thing, particularly when they relate to the most widely-used software in the world, but the situation is not as dire as it originally seemed. There are patches available for all of the vulnerabilities, so a very good starting point is to verify that your systems are up to date on patches. Home users and small network operators likely had the patches installed automatically in the last update, but it is always good to double-check. If you are unsure if you are up to date on these patches, we have checks for them all in Rapid7 Nexpose and Rapid7 InsightVM. These checks are all included in the Microsoft hotfix scan template. EternalBlue EternalSynergy EternalRomance EternalChampion MS17-010 msft-cve-2017-0143 msft-cve-2017-0144 msft-cve-2017-0145 msft-cve-2017-0146 msft-cve-2017-0147 msft-cve-2017-0148 EmeraldThread MS10-061 WINDOWS-HOTFIX-MS10-061 EskimoRoll MS14-068 WINDOWS-HOTFIX-MS14-068 EducatedScholar MS09-050 WINDOWS-HOTFIX-MS09-050 EclipsedWing MS08-067 WINDOWS-HOTFIX-MS08-067 If you want to ensure your patching efforts have been truly effective, or understand the impact of exploitation, you can test your exposure with several modules in Rapid7 Metasploit: EternalBlue MS17-010 auxiliary/scanner/smb/smb_ms17_010 EmeraldThread MS10-061 exploit/windows/smb/psexec EternalChampion MS17-010 auxiliary/scanner/smb/smb_ms17_010 EskimoRoll MS14-068 / CVE-2014-6324 auxiliary/admin/kerberos/ms14_068_kerberos_checksum EternalRomance MS17-010 auxiliary/scanner/smb/smb_ms17_010 EducatedScholar MS09-050 auxiliary/dos/windows/smb/ms09_050_smb2_negotiate_pidhigh, auxiliary/dos/windows/smb/ms09_050_smb2_session_logoff, exploits/windows/smb/ms09_050_smb2_negotiate_func_index EternalSynergy MS17-010 auxiliary/scanner/smb/smb_ms17_010 EclipsedWing MS08-067 auxiliary/scanner/smb/ms08_067_check exploits/windows/smb/ms08_067_netapi In addition, all of the above exploits can also be pivoted to a Meterpreter session via the DoublePulsar implant. What else can you do to protect yourselves? If patching is still in progress or will take a little bit longer to fully implement (we get it) then there are detections for the exploits that you can implement while patching in underway. For examples of ways to implement detections, check out this blog post from Mike Scutt. Rapid7 InsightIDR, our solution for incident detection and response, has an active Threat Community with intelligence to help detect the use of these exploits and any resulting attacker behavior. You can subscribe to this threat in the community portal. For more on how threat intel works in InsightIDR, check out this 4-min Solution Short. It is also important to stay aware of other activity on your network during the patching and hardening processes. It is easy to get distracted by the latest threats, and attackers often take advantage of defender preoccupation to achieve their own goals, which may or may not have anything to do with this latest tool leak. What about that IIS 6 box we have on the public internet? It is very easy for commentators to point fingers and say that anyone who has legacy or unsupported systems should just get rid of them, but we know that the reality is much more complicated. There will be legacy systems (IIS 6 and otherwise) in organizations that for whatever reason cannot just be replaced or updated. That being said, there are some serious issues with leaving systems that are vulnerable to these exploits publicly accessible. Three of the exploits (“EnglishmanDentist”, “EsteemAudit”, and “ExplodingCan”) will remain effective on EOL systems and the impacts are concerning enough that it is really not a good idea to have internet-facing vulnerable systems. If you are in this position we recommend coming up with a plan to update the system and to keep a very close eye on the development of this threat. Due to the sophistication of this tool set, if widespread exploitation starts then it will likely only be a matter of time before the system is compromised. Should you be worried about the Equation Group? The threat from Equation Group itself to most organizations is minimal, unless your organization has a very specific threat profile. Kaspersky's initial analysis of the group lists the countries and sectors that they have seen targeted in the past. This information can help you determine if your organization may have been targeted. While that is good news for most organizations, that doesn't mean that there is no cause for concern. These tools appear to be very sophisticated, focusing on evading security tools such as antivirus and generating little to no logging on the systems that they target. For most organizations the larger threat is that of attackers co-opting these very sophisticated and now public exploits and other post-exploitation tools and using them to achieve their own goals. This increases the threat and makes defending against, and detecting, these tools more critical. We have seen a sharp decrease in the amount of time it take criminals to incorporate exploits into their existing operations. It will not be long before we will start to see more widespread attacks using these tools. Where should I build my underground bunker? While this particular threat is by no means a reason to go underground, there are plenty of other reasons that you may need to hide from the world and we believe in being prepared. That being said, building your own underground bunker is a difficult and time consuming task, so we recommend that you find an existing bunker, pitch in some money with some friends, and wait for the next inevitable bunker-level catastrophe to hit, because this isn't it.

Combining Responder and PsExec for Internal Penetration Tests

By Emilie St-Pierre, TJ Byrom, and Eric Sun Ask any pen tester what their top five penetration testing tools are for internal engagements, and you will likely get a reply containing nmap, Metasploit, CrackMapExec, SMBRelay and Responder. An essential tool for any whitehat, Responder is…

By Emilie St-Pierre, TJ Byrom, and Eric Sun Ask any pen tester what their top five penetration testing tools are for internal engagements, and you will likely get a reply containing nmap, Metasploit, CrackMapExec, SMBRelay and Responder. An essential tool for any whitehat, Responder is a Python script that listens for Link-Local Multicast Name Resolution (LLMNR), Netbios Name Service (NBT-NS) and Multicast Domain Name System (mDNS) broadcast messages (Try saying that out loud 5 times in a row!). It is authored and maintained by Laurent Gaffie and is available via its GitHub repository, located at https://github.com/lgandx/Responder. Once you find yourself on an internal network, Responder will quickly and stealthily get user hashes when systems respond to the broadcast services mentioned above. Those hashes can then be cracked with your tool of choice. As Responder's name implies, the script responds to the broadcast messages sent when a Windows client queries a hostname that isn't located within the local network's DNS tables. This is a common occurrence within Windows networks, and a penetration tester doesn't need to wait too long before capturing such broadcast traffic. Behold our beautiful diagram to help visualize this concept: Due to the client viewing any reply as legitimate, Responder is able to send its own IP as the query answer, no questions asked. Once received, the client then sends its authentication details to the malicious IP, resulting in captured hashes. And believe us, it works - we've seen penetration testers get hashes in a matter of seconds using this tool, which is why it is used early within an internal engagement's timeline. If no hashes are captured via the first method, Responder can be also be used to man-in-the-middle Internet Explorer Web-Proxy Autodiscovery Protocol (WPAD) traffic. In a similar manner to the previous attack, Responder replies with its own IP address for clients querying the network for the “wpad.dat” Proxy Auto-Config (PAC) file. If successful, Responder once again grabs the hashes which can then be cracked, or if time is of the essence, used to pass-the-hash with PsExec (PsExec examples) as we will demonstrate below. Once hashes have been captured, it's time to get cracking! Responder saves all hashes as John Jumbo compliant outputs and a SQLite database. A reliable cracking tool such as John the Ripper can be used to complete this step. Even if cracking is unsuccessful, hashes can be used to validate access to other areas of the target network. This is the beauty of using Responder in conjunction with PsExec. PsExec is a Windows-based administrative tool which can be leveraged to move laterally around the target network. It is useful to launch executables, command prompts and processes on systems. There are numerous tools available for penetration testers who wish to take advantage of PsExec's availability within a network. For example, Metasploit has over 7 PsExec-related modules, its most popular ones being psexec and psexec_psh. There's also the previously-mentioned Windows executable and Core Security's impacket psexec python script. All are potential options depending on the penetration tester's preferences and tool availability. Many networks today struggle to reliably detect remote code execution, which is why it's very common for penetration testers to use Responder and PsExec in the early stages of an engagement. This is due to default Windows environment configurations, as well as protocol-specific behavior which by default trusts all responses.  Fortunately, such attacks can be prevented and detected. To mitigate the first attack we mentioned using Responder's broadcast attacks, these can be prevented by disabling LLMNR and NBT-NS. Since networks already use DNS, these protocols aren't required unless you're running certain instances of Windows 2000 or earlier (in which case, we recommend a New Year's resolution of upgrading your systems!). To prevent the second showcased Responder attack caused by WPAD traffic, it is simply a matter of adding a DNS entry for ‘WPAD' pointing to the corporate proxy server. You can also disable the Autodetect Proxy Settings on your IE clients to prevent this attack from happening. If your company uses Rapid7's InsightIDR, you can detect use of either Responder or PSExec. Our development team works closely with our pen-test and incident response teams to continuously add detections across the Attack Chain. For that reason, the Insight Endpoint Agent in real-time collects the data required to detect remote code execution and other stealthy attack vectors. For a 3-minute overview on InsightIDR, our incident detection and response solution that combines User Behavior Analytics, SIEM, and EDR, check out the below video. Rapid7 InsightIDR 3-Min Overview - YouTube References: https://github.com/lgandx/Responder /2013/03/09/psexec-demysti fied https://github.com/CoreSecurity/impacket/blob/master/examples/psexec.py http://www.openwall.com/john/ https://www.microsoft.com/en-us/download/details.aspx?id=36036 https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283

Preparing for GDPR

GDPR is coming….. If your organisation does business with Europe, or more specifically does anything with the Personal Data of EU Citizens who aren't dead (i.e. Natural Persons), then, just like us, you're going to be in the process of living the dream…

GDPR is coming….. If your organisation does business with Europe, or more specifically does anything with the Personal Data of EU Citizens who aren't dead (i.e. Natural Persons), then, just like us, you're going to be in the process of living the dream that is Preparing for the General Data Protection Regulation. For many organisations, this is going to be a gigantic exercise, as even if you have implemented processes and technologies to meet with current regulations there is still additional work to be done. Penalties for infringements of GDPR can be incredibly hefty. They are designed to be dissuasive. Depending on the type of infringement, the fine can be €20 million, or 4% of your worldwide annual turnover, depending on which is the higher amount. Compliance is not optional, unless you fancy being fined eye-watering amounts of money, or you really don't have any personal data of EU citizens within your control. The Regulation applies from May 25th 2018. That's the day from which organisations will be held accountable, and depending on which news website you choose to read, many organisations are far from ready at the time of writing this blog. Preparing for GDPR is likely to be a cross-functional exercise, as Legal, Risk & Compliance, IT, and Security all have a part to play. It's not a small amount of regulation (are they ever?) to read and understand either – there are 99 Articles and 173 Recitals. I expect if you're reading this, it's because you're hunting for solutions, services, and guidance to help you prepare. Whilst no single software or services vendor can act as a magic bullet for GDPR, Rapid7 can certainly help you cover some of the major security aspects of protecting Personal Data, in addition to having solutions to help you detect attackers earlier in the attack chain, and service offerings that can help you proactively test your security measures, we can also jump into the fray if you do find yourselves under attack. Processes and procedures, training, in addition to technology and services all have a part to play in GDPR. Having a good channel partner to work with during this time is vital as many will be able to provide you with the majority of aspects needed. For some organisations, changes to roles and responsibilities are required too – such as appointing a Data Protection Officer, and nominating representatives within the EU to be points of contact. So what do I need to do?If you're just beginning in your GDPR compliance quest, I'd recommend you take a look at this guide which will get you started in your considerations. Additionally, having folks attend training so that they can understand and learn how to implement GDPR is highly recommended – spending a few pounds/euros/dollars, etc on training now can save you from the costly infringement fines later on down the line. There are many courses available – in the UK I recently took this foundation course, but do hunt around to find the best classroom or virtual courses that make sense for your location and teams.Understanding where Personal Data physically resides, the categories of Personal Data you control and/or process, how and by whom it is accessed, and how it is secured are all areas that you have to deal with when complying with GDPR. Completing Privacy Impact Assessments are a good step here. Processes for access control, incident detection and response, breach notification and more will also need review or implementation. Being hit with a €20million fine is not something any organisation will want to be subject to. Depending on the size of your organisation, a fine of this magnitude could easily be a terminal moment. There is some good news, demonstrating compliance, mitigating risk, and ensuring a high level of security are factors that are considered if you are unfortunate to experience a data breach. But ideally, not being breached in the first place is best, as I'm sure you‘d agree, so this is where your security posture comes in. Article 5, which lists the six principles of processing personal data, states that personal data must be processed in an appropriate manner as to maintain security. This principal is covered in more detail by Article 32 which you can read more about here.Ten Recommendations for Securing Your EnvironmentEncrypt data – both at rest and in transit. If you are breached, but the Personal Data is in a render unintelligible to the attacker then you do not have to notify the Data Subjects (See Article 34 for more on this). There are lots of solutions on the market today – have a chat to your channel partner to see what options are best for you. Have a solid vulnerability management process in place, across the entire ecosystem. If you're looking for best practices recommendations, do take a look at this post. Ensuring ongoing confidentiality, integrity and availability of systems is part of Article 32 – if you read Microsoft's definition of a software vulnerability it talks to these three aspects. Backups. Backups. Backups. Please make backups. Not just in case of a dreaded ransomware attack; they are a good housekeeping facet anyway in case of things like storage failure, asset loss, natural disaster, even a full cup of coffee over the laptop. If you don't currently have a backup vendor in place, Code42 have some great offerings for endpoints, and there are a plethora of server and database options available on the market today. Disaster recovery should always be high on your list regardless of which regulations you are required to meet.Secure your web applications. Privacy-by-design needs to be built in to processes and systems – if you're collecting Personal Data via a web app and still using http/clear text then you're already going to have a problem. Pen tests are your friend. Attacking your systems and environment to understand your weak spots will tell you where you need to focus, and it's better to go through this exercise as a real-world scenario now than wait for a ‘real' attacker to get in to your systems. You could do this internally using tools like Metasploit Pro, and you could employ a professional team to perform regular external tests too. Article 32 says that you need to have a process for regularly testing, assessing, & evaluating the effectiveness of security measures. Read more about Penetration testing in this toolkit.Detect attackers quickly and early. Finding out that you've been breached ~5 months after it first happened is an all too common scenario (current stats from Mandiant say that the average is 146 days after the event). Almost 2/3s of organisations told us that they have no way of detecting compromised credentials, which has topped the list of leading attack vectors in the Verizon DBIR for the last few years. User Behaviour Analytics provide you with the capabilities to detect anomalous user account activity within your environment, so you can investigate and remediate fast.Lay traps. Deploying deception technologies, like honey pots and honey credentials, are a proven way to spot attackers as they start to poke around in your environment and look for methods to access valuable Personal Data.  Don't forget about cloud-based applications. You might have some approved cloud services deployed already, and unless you've switched off the internet it's highly likely that there is a degree of shadow IT (a.k.a. unsanctioned services) happening too. Making sure you have visibility across sanctioned and unsanctioned services is a vital step to securing them, and the data contained within them. Know how to prioritise and respond to the myriad of alerts your security products generate on a daily basis. If you have a SIEM in place that's great, providing you're not getting swamped by alerts from the SIEM, and that you have the capability to respond 24x7 (attackers work evenings and weekends too). If you don't have a current SIEM (or the time or budget to take on a traditional SIEM deployment project), or you are finding it hard to keep up with the number of alerts you're currently getting, take a look at InsightIDR – it covers a multitude of bases (SIEM, UBA and EDR), is up and running quickly, and generates alert volumes that are reasonable for even the smallest teams to handle. Alternatively, if you want 24x7 coverage, we also have a Managed Detection and Response offering which takes the burden away, and is your eyes and ears regardless of the time of day or night.Engage with an incident response team immediately if you think you are in the midst of an attack. Accelerating containment and limiting damage requires fast action. Rapid7 can have an incident response engagement manager on the phone with you within an hour. Security is just one aspect of the GDPR, for sure, but it's very much key to compliance. Rapid7 can help you ready your organisation, please don't hesitate to contact us or one of our partners if you are interested in learning more about our solutions and services. GDPR doesn't have to be GDP-argh!

12 Days of HaXmas: Designing Information Security Applications Your Way

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 days of blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while…

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 days of blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. Are you a busy Information Security professional that prefers bloated web applications, fancy interactions, unnecessary visuals, and overloaded screens that are difficult to make sense? No…I didn't think so! Being a designer, I cringe when I see that sort of stuff, and it's something we avoid at all cost at Rapid7. You don't even have to be a designer to dislike it. My mantra mirrors that of Derek Featherstone, who said “Create the minimum viable interaction by providing the most valuable piece of information for decision-making as early as possible.” And focusing on good design is the gift I bring to you this HaXmas! To bring you this gift, I am always learning about new ways to solve the problems that you and your teams face on a day-to-day basis. That learning comes from many sources, including our customers, books, webinars, blog posts, and events. One notable event this year was the aptly named An Event Apart, held in Boston. An event what? An Event Apart is a tech conference for designers and developers to learn,and to be inspired by, the latest design trends and coding techniques that improve the way we deliver applications. While other conferences tend to focus only on design, this conference does much more by bringing a variety of topics under one umbrella, including coding, web and mobile app design. To that end, every speaker at An Event Apart is pretty famous in our world—it was great to see them in real life! Three days and twelve presentations later, my head was swimming with ideas. But the most important themes I brought away were to: Design the priority Speed it up Be more compassionate Let's look at each of these concepts one-by-one and see how they apply to the way we designed InsightIDR, Rapid7's Incident and Detection Response tool, which allows security teams to detect intruders earlier in the attack chain. Design the priority At the conference, Ethan Marcotte, the father of Responsive Design, said “Design the priority, not the layout”. Ethan mentioned this because designers tend to consider the layout of an application screen first. Unfortunately, this approach has a tendency to throw out the signal-to-noise ratio. Jeffrey Zeldman agreed with Ethan when he said, “Design your system to serve your content, not the other way around.” This concept has really come to the forefront with the Mobile First approach from Luke Wroblewski, who argues that "Mobile forces you to focus". Well, I argue that you do not need to be mobile to focus! This concept is just as important on a 27” screen as it is on a 5” screen. As we design InsightIDR, we design the priority, not the layout, by helping our customers focus on the right content. As you can see on the InsightIDR design to the left, the KPIs are placed in order of importance, with date and trending information, allowing our customers to prioritize their next actions as they protect their organizations. This results in a better user experience, and time saved for other tasks. Speed it up According to Jeffrey Zeldman, the applications we build need to be fast. Very. Fast. Commonsense, I hear you say, and I agree completely. But that's no easy thing when you are collecting, analyzing, and sorting the amount of information that InsightIDR captures. Can we sit back and start to think that our customers would understand if it takes a few seconds for a page to load? Not at all! Yesenia Perez-Cruz, design director at Vox Media, suggests that organizations need to better plan for a more strategic way to decrease the file size of web application pages, while concurrently increasing load times. We have taken Jeffrey's and Yesenia's message to heart, as we strive to ensure the pages and content within InsightIDR load as quickly as possible, so you can get your job done faster. Be more compassionate Being compassionate by standing in the shoes of the people we design for might seem like a no-brainer. After all, the ‘U' stands for ‘User' in my job title ‘UX Designer.' Yet, some designers do not take the time to actually speak with the people they are designing for. But at Rapid7, I speak with customers about their security needs through our customer voice program on a regular basis. The customers that have signed up for the program have a say in the features we design, and they get to see those designs early so they can, in effect, co-design with us by letting us know how to modify the designs to make them more effective. Only then can I and the rest of the UX team at Rapid7 truly design for you. In this respect, as Patty Toland, a regular An Event Apart speaker, says “Design consistency isn't pixels; it is purpose.” Wrapping up At Rapid7, I am always learning about design, about our customers' needs, and about the future of information security. So, if you are in Boston and hear someone on the T softly say “Create the minimum viable interaction by providing the most valuable piece of information for decision-making as early as possible,” that will probably be me as I go to work.  On a more serious note, if you have not done so already, make sure you sign up for our Voice Program to see what's in the works, and have a say in what we do and how we do it. Here are a few links to that program if you are interested: Rapid7 Voice: https://www.rapid7.com/about/rapid7-voice/ Rapid7 Voice email: Rapid7Voice [at] rapid7 [dot] com I look forward to speaking with you in the near future, as we work together to design the next version of InsightIDR! Thanks for reading, and have a wonderful HaXmas! Kevin Lin, UX Designer II Rapid7 Image credits: First image: An Event Apart (©eventifier.com, @heyoka) Second image: insightIDR

Introspective Intelligence: What Makes Your Network Tick, What Makes It Sick?

In my last blog post, we reviewed the most prevalent detection strategies and how we can best implement them. This post dives into understanding how to catch what our other systems missed, using attacker behavior analytics and anomaly detection to improve detection.Understand Your Adversary…

In my last blog post, we reviewed the most prevalent detection strategies and how we can best implement them. This post dives into understanding how to catch what our other systems missed, using attacker behavior analytics and anomaly detection to improve detection.Understand Your Adversary – Attack Methodology DetectionContextual intelligence feeds introduce higher fidelity and the details needed to gain insight into patterns of attacker behavior. Attackers frequently rotate tools and infrastructure to avoid detection, but when it comes to tactics and techniques, they often stick with what works. The methods they use to deliver malware, perform reconnaissance, and move laterally in a network do not change significantly.A thorough understanding of attacker methodology leads to the creation and refinement of methodology-based detection techniques. Knowledge of applications targeted by attackers enables more focused monitoring of those applications for suspicious behaviors, thus optimizing the effectiveness and efficiency of an organization's detection program. An example of application anomaly-based detection is webshells on IIS systems:It is anomalous for IIS to spawn a command prompt, and the execution of “whoami.exe” and “net.exe” indicate likely reconnaissance activity. By understanding the methods employed by attackers we generate detections that will identify activity without relying on static indicators such as hashes or IPs. In this case we are using the low likelihood of IIS running CMD and the rare occurrence of CMD executing ‘whoami' and ‘net [command]' to drive our detection of potential attacker activity.Additionally, attackers must reconnoiter networks both internally and externally to identify target systems and users. Reviewing logs for unusual user-to-system authentication events, suspicious processes (for example, ‘dsquery', ‘net dom', ‘ping –n 1', and ‘whoami'), especially over abbreviated time periods, can provide investigative leads to identify internal reconnaissance.Even without a constant stream of real-time data from endpoints, we can model behavior and identify anomalies based upon the frequency of an item across a group of endpoints. By gathering data on persistent executables across a network, for example, we can perform frequency analysis and identify rare or unique entries for further analysis. Simple techniques like frequency analysis will often reveal investigative leads from prior (or even current) compromises, and can be applied to all manner of network and endpoint data.Expanding beyond a reliance primarily on traditional static indicator-based detection and adding a focus on attacker behavior increases the likelihood of detecting previously unknown malware and skilled attackers. A culmination of multiple detection strategies is necessary for full coverage and visibility: proactive detection technology successfully blocks known-bad, contextual intelligence assists in identifying less common malware and attackers, and methodology-based evidence gathered from thorough observation provides insight into potential indicators of compromise.Use the Knowledge You HaveIT and security staff know their organization's users and systems better than anyone else. They work diligently on their networks every day ensuring uptime of critical components, enablement of user actions, and expedient resolution of problems. Their inherent knowledge of the environment provides incredible depth of detection capabilities. In fact, IT support staff are frequently the first to know something is amiss, regardless if the problem is caused by attacker activity.  Compromised systems may often exhibit unusual symptoms and become problematic for users, who report the problems to their IT support staff.Environment-specific threat detection is Rapid7's specialty. Our InsightIDR platform continuously monitors user activity, authentication patterns, and process activity to spot suspicious behavior. By tracking user authentication history, we can identify when a user authenticates to a new system, over a new protocol, and from a new IP. By tracking the processes executed on each system we can identify if a user is running applications that deviate from their normal patterns or if they are running suspicious commands (based on our knowledge of attacker methodology). Combining user authentication with process execution history ensures that even if an attacker accesses a legitimate account, his tools and reconnaissance techniques will give him away. Lastly, by combining this data with threat intelligence from previous findings, industry feeds, and attacker profiles we ensure that we prioritize high-fidelity investigative leads and reduce overall detection time, enabling faster and more effective response.Let's walk through an example: Bob's account is compromised internally:After compromising the system, an attacker would execute reconnaissance commands that are historically dissimilar to Bob's normal activity. Bob does not typically run ‘whoami' on the command line or execute psexec, nor has Bob ever executed a powershell command – those behaviors are investigative elements that individually are not significant enough to alert on, but in aggregate present a trail of suspicious behavior that warrants an investigation.Knowledge of your environment and what is statistically ‘normal' per user and per system enables a ‘signature-less' addition to your detection strategy. Regardless of the noisy and easily bypassed malware hashes, domains, IPs, IDS alerts, firewall blocks, and proxy activity your traditional detection technology provides, you can identify attacker activity and ensure that you are not missing events due to stale or inaccurate intel.Once you have identified an attack based on user and system anomaly detection, extract useful indicator data from your investigation and build your own ‘known-bad' threat feed. By adding internal indicators to your traditional detection systems, you have greater intel context and you can simplify the detection of attacker activity throughout your environment. Properly combining detection strategies dramatically increases the likelihood of attack detection and provides you with the context you need to differentiate between ‘weird', ‘bad', and ‘there goes my weekend'.

User Behavior Analytics and Privacy: It's All About Respect

When I speak with prospects and customers about incident detection and response (IDR), I'm almost always discussing the technical pros and cons. Companies look to Rapid7 to combine user behavior analytics (UBA) with endpoint detection and log search to spot malicious behavior in their environment.…

When I speak with prospects and customers about incident detection and response (IDR), I'm almost always discussing the technical pros and cons. Companies look to Rapid7 to combine user behavior analytics (UBA) with endpoint detection and log search to spot malicious behavior in their environment. It's an effective approach: an analytics engine that triggers based on known attack methods as well as users straying from their normal behavior results in high fidelity detection. Our conversations center on technical features and objections – how can we detect lateral movement, or what does the endpoint agent do, and how can we manage it? That's the nature of technical sales, I suppose. I'm the sales engineer, and the analysts and engineers that I'm speaking with want to know how our stuff works. The content can be complex at times, but the nature of the conversation is simple. An important conversation that is not so simple, and that I don't have often enough, is a discussion on privacy and IDR. Privacy is a sensitive subject in general, and over the last 15 years (or more), the security community has drawn battle lines between privacy and security.  I'd like to talk about the very real privacy concerns that organizations have when it comes to the data collection and behavioral analysis that is the backbone of any IDR program. Let's start by listing off some of the things that make employers and employees leery about incident detection and response. It requires collecting virtually everything about an environment. That means which systems users access and how often, which links they visit, interconnections between different users and systems, where in the world users log in from – and so forth. For certain solutions, this can extend to recording screen actions and messages between employees. Behavioral analysis means that something is always “watching,” regardless of the activity. A person needs to be able to access this data, and sift through it relatively unrestricted. I've framed these bullets in an intentionally negative light to emphasize the concerns. In each case, the entity that either creates or owns the data does not have total control or doesn't know what's happening to the data. These are many of the same concerns privacy advocates have when large-scale government data collection and analysis comes up. Disputes regarding the utility of collection and analysis are rare. The focus is on what else could happen with the data, and the host of potential abuses and misuses available. I do not dispute these concerns – but I contend that they are much more easily managed in a private organization. Let's recast the bullets above into questions an organization needs to answer. Which parts of the organization will have access to this system? Consider first the collection of data from across an enterprise. For an effective IDR program, we want to pull authentication logs (centrally and from endpoints – don't forget those local users!), DNS logs, DHCP logs, firewall logs, VPN, proxy, and on and on. We use this information to profile “normal” for different users and assets, and then call out the aberrations. If I log into my workstation at 8:05 AM each morning and immediately jump over to ESPN to check on my fantasy baseball team (all strictly hypothetical, of course), we'll be able to see that in the data we're collecting. It's easy to see how this makes employees uneasy. Security can see everything we're doing, and that's none of their business! I agree with this sentiment. However, taking a magnifying glass to typical user behavior, such as websites visited or messages sent isn't the most useful data for the security team. It might be interesting to a human resources department, but this is where checks and balances need to start. An information security team looking to bring in real IDR capabilities needs to take a long and hard look at its internal policies and decide what to do with information on user behavior. If I were running a program, I would make a big point of keeping this data restricted to security and out of the hands of HR. It's not personal, HR – there's just no benefit to allowing witch hunts to happen. It'll distract from the real job of security and alienate employees. One of the best alerting mechanisms in every organization isn't technology, it's the employees. If they think that every time they report something it's going to put a magnifying glass on every inane action they take on their computer, they're likely to stop speaking up when weird stuff happens. Security gets worse when we start using data collected for IDR purposes for non-IDR use cases. Who specifically will have access, to what information, and how will that be controlled? What about people needing unfettered access to all of this data? For starters, it's absolutely true. When Bad Things™ are detected, at some point a human is going to have to get into the data, confirm it, and then start to look at more data to begin the response. Consider the privacy implications, though; what is to stop a person from arbitrarily looking at whatever they want, whenever they want, from this system? The truth is organizations deal with this sort of thing every day anyway. Controlling access to data is a core function of many security teams already, and it's not technology that makes these decisions. Security teams, in concert with the many and varied business units they serve, need to decide who has access to all of this data and, more importantly, regularly re-evaluate that level of access. This is a great place for a risk or privacy officer to step in and act as a check as well. I would not treat access into this system any differently than other systems. Build policy, follow it, and amend regularly. Back to if I was running this program. I would borrow pretty heavily from successful vulnerability management exception handling processes. Let's say there's a vulnerability in your environment that you can't remediate, because a business critical system relies on it. In this case, we would put an exception in for the vulnerability. We justify the exception with a reason, place a compensating control around it, get management sign off, and tag an expiration date so it isn't ignored forever. Treat access into this system as an “exception,” documenting who is getting access, why, and define a period in which access will be either re-evaluated or expire, forcing the conversation again. An authority outside of security, such as a risk or privacy officer, should sign off on the process and individual access. Under what circumstances will this system be accessed, and what are the consequences for abusing that access? There need to be well-defined consequences for those that violate the rules and policies set forth around a good incident detection and response system. In the same way that security shouldn't allow HR to perform witch hunts unrelated to security, the security team shouldn't go on fishing trips (only phishing and hunts). Trawls through data need to be justified. This is for the same reasons as the HR case. Alienating our users hurts everyone in the long run. Reasonable people are going to disagree over what is acceptable and what is not, and may even disagree with themselves. One Rapid7 customer I spoke with talked about using an analytics tool to track down a relatively basic financial scam going on in their email system. They were clearly justified in both extracting the data and further investigating that user's activity inside the company. “In an enterprise,” they said, “I think there should be no reasonable expectation of privacy – so any privacy granted is a gift. Govern yourself accordingly.” Of course, not every organization will have this attitude. The important thing here is to draw a distinct line for day to day use, and note what constitutes justification for crossing that line. That information should be documented and be made readily available, not just in a policy that employees have to accept but never read. Take the time to have the conversation and engage with users. This is a great way to generate goodwill and hear out common objections before a crisis comes up, rather than in the middle of one or after. Despite the above practitioner's attitude towards privacy in an enterprise, they were torn. “I don't like someone else having the ability to look at what I'm doing, simply because they want to.” If we, the security practitioners, have a problem with this, so do our users. Let's govern ourselves accordingly. Technology based upon data collection and analysis, like user behavior analytics, is powerful and enables security teams to quickly investigate and act on attackers. The security versus privacy battle lines often get drawn here, but that's not a new battle and there are plenty of ways to address concerns without going to war. Restrict the use of tools to security, track and control who has access, and make sure the user population understands the purpose and rules that will govern the technology. A security organization that is transparent in its actions and receptive to feedback will find its work to be much easier.

Overcome Nephophobia - Don't be a Shadow IT Ostrich!

Overcome Nephophobia - Don't be a Shadow IT Ostrich! Every cloud….. When I was much younger and we only had three TV channels, I used to know a lot of Names of Things. Lack of necessity and general old age has meant I've now long…

Overcome Nephophobia - Don't be a Shadow IT Ostrich! Every cloud….. When I was much younger and we only had three TV channels, I used to know a lot of Names of Things. Lack of necessity and general old age has meant I've now long since forgotten most of them (but thanks to Google, my second brain, I can generally “remember” them again as long as there's data available). Dinosaurs, trees, wild flowers, and clouds were all amongst the subject matters in which my five-year-old self was a bit of an expert. I would point at the sky and wow my parents with my meteorological prowess, all learnt from the pages of a book. Good times. These days I can manage about three cloud names off the top of my head before reaching for the Internet. Cirrus, stratus, cumulonimbus (OK I had to double check the last one).  Failing memory aside, I still love clouds, and frankly there's little that beats a decent sunset – which wouldn't be anywhere near as good without some clouds. So assuming you're still reading and not googling cloud names (because it can't just be me), I'd like you to think of a cloud please, an actual one, not a digital one. Chances are it's all fluffy and white, the cumulus (oh yeah) type. Of all the words I could use to describe a cumulus cloud “scary” isn't one of them. But did you know that Nephophobia - the irrational fear of clouds - is a real condition? Nephophobics struggle to look up into the sky, and in some cases won't even look at a picture of a cloud. Any phobia by its very nature is debilitating, leaving the sufferer feeling anxious at best, or totally unable to function at worst. I live with a six-foot strapping arachnophobe who is reduced to a gibbering wreck at anything larger than a money spider. Digital Nephophobia Nephophobia exists in our digital world too. Use of the cloud is written off and immediately written in to policy. “We don't use the cloud” is something I've heard far too frequently. And sometimes “don't” is more “can't” (blocked from doing so by government regulation) or “won't” (we just don't want to, we don't trust it), but actually “do…but don't know it” is more often the reality. This is where anxiety caused by the cloud is at its most valid – lack of visibility into the cloud services your users are already using (aka Shadow IT) is frankly terrifying for anyone concerned with data privacy or data security. I recently met with an IT Security Manager of a global network, who rightly said “if you're not providing the services your users need and expect, then whether you like it or not you are probably being exposed to Shadow IT”. Pretending it's not happening won't make it go away either, as many a mauled ostrich will merrily testify. Digital Therapy Many phobia therapies involve facing the fear head on. Now I'm not suggesting that the best medicine to cure digital nephophobia is to burn the “we don't use the cloud” policy and open up your network to every cloud service available, far from it. First of all, it's vital to understand what is really happening within your environment now – which cloud services your users have using without your knowledge. From there you can work out which cloud services you should be formally provisioning, which you should be monitoring, and which you should be locking down. Perform the due diligence – any cloud vendor worth their salt will be able to provide you with the reassurance that their service is secured, with in-depth details of how it is secured, what happens to your data in transit and at rest, how it is segmented from other organisations' data, who has access, and more. Set yourself free Once you've worked out what you need, and are confident in the service provider's security processes (which are likely going to be on par or indeed even better than those in your own network), the weight of digital nephophobia will begin to lift. The benefits of using the cloud are huge – a huge reduction in provisioning, administration, and maintenance overheads for a start. The speed in which you can provide new services compared to the old world of doing it all in-house is staggering – how many times have you heard users moan about how long it takes IT to bring in a new service? Speaking of moaning – how about those 79 bajillion helpdesk tickets and IMs and calls that come in because The Server's Down….Again? Distant memories – uptime is another benefit to embracing cloud services.  You'll be in good company too - organisations from every vertical are using the cloud – financial institutions, governments, healthcare, defense, manufacturing, charities, the list goes on and on. Tackling Shadow IT is the first step in the journey from Nephophobe to Nephophile Our aforementioned ostrich friend wants to be a lesson to you. If you can't see where your problems are, you can't begin to do something about them, and if you bury your head in the sand you are in dire risk of becoming lion lunch. Visibility into cloud services, whether they are sanctioned or shadow IT services, is a string that every IT Security professional needs to have in their bow. InsightIDR gives you that string (and a whole bunch more too!) – at the tips of your fingers lies a wealth of information on which cloud apps are being accessed, who is using them, when they are being used, and how frequently. And you don't have to code a bunch of complex queries to access this information – the interactive dashboard has it all: Want to learn more about how InsightIDR gives organisations insight into cloud services, user behaviour, and accelerates incident investigations by over 20x (told you there were more bow strings available!)? We'd love to show you a demo. And if you would like to know more about our approach to cloud platform security you can read all about here right here.

Analytics By Any Other Name: New InsightIDR Detections Released

New detections have been introduced regularly since we first started developing our Incident Detection and Response (IDR) solutions four years ago. In fact, as of today, we have a collection of more than 50 of these running across customer data. But what does that mean?…

New detections have been introduced regularly since we first started developing our Incident Detection and Response (IDR) solutions four years ago. In fact, as of today, we have a collection of more than 50 of these running across customer data. But what does that mean? And what are the very latest detections to help your security program? Vendors have fancy names for what is under the covers of their tools: “machine learning,” “advanced analytics,” “autonomous sentient artificial intelligence” – ok, I made up the last one, but I bet you could see a vendor using that in their next press release. Our InsightIDR solution uses a variety of analytics, machine learning, and deception technology, but our customers don't necessarily worry about what we call it, at the end of the day they want one thing: detections of nefarious behavior. No matter what you call it, the primary reason that InsightIDR's detections are so effective is that we rely on Rapid7's team of attack-minded experts to actually help develop the detection techniques that span the attack chain. Sure, some detections require extensive baselining of all user behavior, some require deception technology, and some require advanced log correlation. And while you can't detect everything, you must continually prioritize the most effective attacker techniques for various stages of the chain and apply a bit of the scientific method to detect them. In that spirit, we recently introduced three new detections to InsightIDR that demonstrate how different the technology for each real world attacker technique may be when you're looking for indicators at each stage of the attack chain. And, since it fits well into National Cybersecurity Awareness month, I'd like to raise awareness about realistic attacker techniques to demonstrate why these new detections are more than just average IOCs_._ We want to make it uncomfortable for attackers exploring your network, forcing them from a casual jog through the forest to being afraid to take the wrong step like they've been dropped into a forest in The Hunger Games. NetBIOS Name Service Poisoning – know when someone is tricking your Windows machines into sharing credentials. You probably didn't see it, since few people did, but Terminator 3 brought a new terminator model, T-X, with a significant improvement over the terrifying T-1000: the ability to impersonate both a human and a weapon. While both the T-800 model and T-1000 were terrifying, they clearly had their limitations. When T-800 imitated a [ridiculously fit] human being, it made detecting threats more difficult than looking for shiny metal, but the T-1000 was able to pretend to be any person, including those of authority and yet, in Arnold's own words, it couldn't form “complex machines.” This is what made the next T-X model even more terrifying and hard to detect: it could pose as a human and form complex machines. Similarly, there are many SIEM implementations capable of detecting brute force attempts to impersonate humans by stealing their accounts and a bevy of new user behavior analytics vendors claiming they can spot the T-1000 impersonating an authority figure to access more critical systems, but neither is able to spot a very common complex machine: protocol poisoning. Today, it is very easy for both simulated and real attackers, once on the network, to listen and respond to requests to resolve host names broadcast over the local network segment with tools like Responder. In his retelling of his Hacking Team hack, Phineas Fisher called it “The most useful tool for attacking windows networks when you have access to the internal network, but no domain user.” Despite attackers pretending to be these trusted systems within the organization, the vast majority of Rapid7 penetration test clients fail to detect this behavior, even with massive detection investments. This is why the Rapid7 InsightIDR team strove to make it absurdly easy to detect. Since InsightIDR already has a presence on the network, the Insight agents are instructed to issue queries for non-existent host names over NBT-NS (as the most vulnerable systems would) and any received responses will expose the spoofer. It's a little like asking what's wrong with “Wolfie” when the real mom would clearly know the dog is named “Max” [and yes, I know that was the T-1000 – I barely remember T3]. EMET – install it. Right now. Then, actually monitor what it sees. In one of Hollywood's best movies about barroom brawls, Road House, the hero Dalton rented a comfortable room from an unassuming man named “Emmett.”  Emmett was not only a source of comic relief when his house was set ablaze, but he turned out to be valuable asset when the real town proprietors decided to take their town back. We'll never know whether Dalton should have confided in Emmett more about his challenges at the Double Deuce, but thanks to the magic of hindsight, it seems like he would have at least been a valuable source of information. One of the biggest failings of the security industry is the fact that Microsoft's free Exploit Mitigation Experience Toolkit (EMET – not pronounced the same, I think) is not currently installed on every Windows machine in existence. We can examine the reasons why in another blog someday, but if your organization actually does have the EMET agent installed broadly, your biggest question is probably whether anything is getting actively blocked by EMET. If you want to find out, you can spend a lot of time managing the Windows Event Collector and building correlation rules or you can simply deploy InsightIDR and receive these alerts alongside all of the notable behaviors and alerts across the attack chain for each user and asset. This valuable source of information can quickly show you someone is on the network attempting to exploit systems, and even when though they were effectively mitigated, this means you can take action much earlier in the attack chain. Related: [VIDEO] Why You Should be Using EMET Honey files – because exfiltration is likely to precede the file opening. If you learned everything you know about wealthy people from movies, as I did, you obviously know that cat burglars discreetly come into your house, slink around various monitoring systems, and carefully look through all of your valuables until the right one is identified, just like Clint Eastwood's character in Absolute Power. In this scenario, it may feel like the most effective type of detection is a silent alarm which triggers when each jewelry box is opened, but that could lead to a noise of false alarms [sounds like legacy SIEM]. This is how most people have been forced to detect attacks with file integrity management solutions - by filtering through the thousands of file changes that occur every day and hoping to catch the real problem. It's akin to the false alarms with the jewelry boxes where the alarm is more likely because of a pet bumping the jewelry box or another family member perusing. In the cyber-attack world, cat burglars rarely waste their time opening each and every file on a system until they find the right one. “Smash and grab” is the wrong phrase for it, but they quickly zip entire folders in short order, exfiltrate them to a safe drop server, and move on to the next system because they know their backdoor connection could get severed at any time. This is why the InsightIDR team made it so easy for you to use another form of deception on top of the honey pots, honey users, and honey credentials. If you haven't managed to stop the attack by the time it reaches the “Mission Target” stage, having some useless files there and alerting even if they're copied guarantees you know when someone has reached the valuables. It's like planting a necklace of large, cubic zirconia in a fancy jewelry box and only sounding that silent alarm when the box is swept into the cat burglar's oversized sack of stolen goodies. If you want to learn more about detecting attacks with InsightIDR and the rest of Rapid7's Incident Detection and Response portfolio, we would be happy to give you a free guided demo. Related: [VIDEO] Solution Short - New Detections in InsightIDR

Establishing an Insider Threat Program for Your Organization

Whether employees realize it or not, they can wreak havoc on internal and external security protocols. Employees' daily activities (both work and personal) on their work devices (computers, smartphone, and tablets) or on their company's network can inflict damage. Often called “insider threats,” employees' actions,…

Whether employees realize it or not, they can wreak havoc on internal and external security protocols. Employees' daily activities (both work and personal) on their work devices (computers, smartphone, and tablets) or on their company's network can inflict damage. Often called “insider threats,” employees' actions, both unintentional or intentional, are worth paying heed to whenever possible. Gartner's Avivah Litan reported on this thoroughly in her “Best Practices for Managing Insider Security Threats, 2016 Update,” where it is made clear that businesses aren't on their own in regards to responding to this growing, often unpredictable and unmitigated challenge. Avivah recommends four strong approaches you should consider when developing an insider threat program, which she reinforces with analysis, data, and additional content. In the hopes of expanding this list and providing even more thoughts, Rapid7's security experts, inspired by the four outlined approaches in the report, got together to provide some additional approaches. Where applicable we have also provided links to resources, both product and research, that can help your team combat insider threats. After all, we're in this together! Recommendation #1: “Start insider threat programs with a risk assessment, in order to prioritize efforts. Deploy business processes and technologies that prevent many insider threats in the first place.” Yes, but be wary of risk assessments not tied to your business objectives and limitations. While a risk assessment is a solid starting point, any miscues could do more harm than good. For example, poor risk assessment will actually overload the security team and create paralysis unless it is relevant, actionable, and sustainable. Some risk assessment services use both people and technology to examine your own technologies, people, and processes. But they are not all created equal and it is important to review the way they will measure risk and what tools they might use. It's important to consider two types of risk assessment: a one-off audit done by a third party (like a penetration test or a cybersecurity maturity assessment), as well as continuous assessment and good security hygiene. One thing we often see are risk assessments using tools from the CVSS-only scoring world of legacy vulnerability management players. In this world you are ultimately left with a list of hundreds of ‘critical' vulns, which is a list you'll never get through to even start thinking about insider threats. Even many penetration tests / external risk assessments fall into the trap of providing a list of problems without context and focus on what attackers really care about. It's important for teams to do this risk assessment, but do it in a way that properly prioritizes this beyond CVSS and takes into account the age of the vulns, exploitability, and more. Our solutions can help: In case you didn't know, our solutions, Nexpose and Metasploit, let you go beyond “vulnerability assessment” to exactly what Gartner is suggesting – a RISK assessment. Because Nexpose prioritizes vulnerabilities by the ease with which they'd be used in an attack, our risk scores are a true picture of how susceptible a system is to a breach, whether insider or external. Nexpose vulnerability checks include checks for default passwords, and limiting these vulns make it more difficult for insider threats to access systems they shouldn't. Metasploit lets you conduct simulated phishing attacks on your employees, and it lets you test their ability to spot not just suspicious links but suspicious requests for information. Recommendation #2: “Combine technical methods with nontechnical controls, such as security awareness training linked to employee monitoring, for the most successful results in your insider threat program.” Don't dehumanize the employee experience. People are the key for sure here and security awareness training should run the gamut from overall education to phishing exercises. It's critical for businesses to iterate to employees that although there will be monitoring for security purposes, their privacy can continue to be respected. For a more successful deployment, executive staff and the security team must ensure that employees have transparency and trust into the process. One of the best alerting mechanisms in every organization isn't technology, it's the employees. If users worry about being under the user behavior magnifying glass after they report something, they're likely to stop speaking up when weird stuff happens. A best practice is to have an authority outside of security, such as a risk or privacy officer, explicitly define who has access to the technology, to what information, and ensure that the policy is regularly reviewed and enforced. During security awareness and compliance training, the security team has an opportunity to share the importance of identifying anomalous behavior, since compromised credentials has been a top attack vector behind breaches (Verizon Data Breach Investigations Report) for five years running. Our solutions can help: New technology, such as User Behavior Analytics, can correlate the millions of actions taken on the network to the users and assets behind them. This can expose risky user behavior, whether it be unintentional negligence or malicious insider threat. When InsightIDR is first deployed in a customer environment, the technology starts to create a baseline of typical user behavior. Many organizations immediately improve their security posture and validate existing controls by identifying non-expiring passwords, shared accounts, and administrators they otherwise did not know about. From there, InsightIDR highlights notable and anomalous behavior that may be indicative of a compromised or rogue employee account. Recommendation #3: “(For technical insider threat programs) Start with readily available data, such as directory data and access logs, to achieve quicker results. Increase the types of information ingested over time, recognizing analytics can only be as good as the data they consume.” Yes and YES. This is something we truly believe in, and we think that you can not only get a lot out of the data you already have, but you can do it more easily than ever before. If you want to identify insider threats, you need to first understand what is normal behavior for your users and the first step is to tie the majority of events back to those users. This requires Active Directory, to provide details on who is logged into each device at any given time, and it requires DHCP, to know which IP address is assigned to these devices. The next big step is to obtain endpoint data, such as local event logs and process details, to increase the types of behavior you can see. Ultimately, start with basic data analytics to look for known patterns of malicious behavior and look for solutions that have automated the collection, unification, and correlation of your data. It is also smart to add on top of that folks who have done this before in order to get immediate benefit for any security analytics program. Our solutions can help: In general, insider threats are a risk to an organization, whether they're intentional or unintentional. Rapid7 combines both technology, with our InsightIDR solution, and a team of incident responders constantly understand what the highest risk users and assets are in the organization. This evaluation is not just a look at the technological systems, but it's also a deep understanding of the business. This allows the team to be more targeted in their hunting for threats later and to put policies in place to minimize insider threat risk later on. The time up front makes it easier to mitigate risk through prioritization of what's most important to the organization. The deep knowledge the team has of attacker behavior and user behavior helps them better identify insider threats. Recommendation #4: “Start with basic data analytics to look for known patterns of malicious behavior. Graduate to more advanced analytics like anomaly detection once your organization is able to manage the results.” Analytics reign supreme. This is where the focus of analytics needs to be more automated. Let's assume you've done all the above, and did it right, the last thing you now want to do is learn how to write or even manage analytics. Focus on automating the analysis as much as possible. This isn't about just having a library of analytics created with an attacker's mindset, it also needs to be considered in how log search is performed and visualized. It's no longer acceptable to spend time data splunking around when your goal is to find that insider threat before it hurts you. Our solutions can help: If you don't have log aggregation in place, this is a great start, as it will save you lots of time and headaches during incident investigations, and is an integral part of meeting today's compliance standards. Most log aggregation tools come with the ability to create custom alerts, which can help solve basic use-cases and provide visibility into the environment. InsightIDR works by creating a User-IP-Asset link from integrating with Active Directory, DHCP, and Endpoint Data, as well as an existing network and security stack. What takes InsightIDR beyond just analyzing logs are Intruder Traps, such as Honey Pots and Honey Credentials, which reliably detect intruders earlier in the attack chain. Ultimately, there's a lot of methods to consider when developing an insider threat program. But as can be seen above, not all approaches are made equal. It's imperative to be thoughtful and conscientious about how insider threats are approached and handled.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More


Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now


Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now