New F5 ASM Version 12.x Features Improve Performance

In today’s blog, we will discuss the newest features of F5’s Web Application Firewall (WAF), Application Security Manager (ASM). ASM has been around for quite some time, but with recent updates I thought it is worth discussion.

F5 Networks recently released version 12.1.1, the first long-term support release for version 12. If you haven’t read through the release notes, take a few minutes and do so. I am really excited by some of the most recent features and I would like to share some of them with you.

I was ecstatic to see Unified Policy Building in 12.0 because now you have one screen to view all learning suggestions. This makes it far easier to sort through. If your policy builds automatically or statically based on your custom thresholds, you now have only one screen to manage.

Following the style already set in ASM, there is a dropdown menu that allows you to select the policy for which you want to see suggestions. Tabbed across the top is also Enforcement Readiness, and they moved Learning and Blocking Settings here as well. This makes the overall flow better while making it easier to see which settings you have for each selected policy — no more bouncing around the mouseover menus.

Next up in 12.0 is Proactive Bot Defense. This is a set of additional features added to the Denial of Service (DoS) functions ASM already used. F5 added improved defense against unwanted browsers and browsing agents that are non-human initiated. CAPTCHA and javascript insertion does this, but with some caveats. If you use CORS (Cross-Origin Resource Sharing), like with AJAX calls, you will have issues and you should add those URLs to the bot whitelist.

F5 Networks also added malicious bot signatures. Now when you update your ASM application signatures, bot signatures are classified as malicious or benign. Just like with application signatures, you can create your bot signatures as well. You even have the ability to create signature sets with either malicious or benign classifications. This gives you greater control. Once created and applied via a “dos” profile, traffic is automatically classified and either accepted or discarded as configured.

Version 12.1 was not outshined by 12.0, and really cranked up the dial. It added more dos enhancements with the ability to track using device IDs. Now device IDs can use dos, brute force, and session hijacking. You can define bad behavior and set thresholds to classify traffic from them and either log or block them. F5 even extended Analytics to sort by these IDs. More reporting is always a good thing!

Using a similar set of metric definitions, you can now automatically blacklist IPs attacking your layer 7 resources and increase your dos footprint. This does not require use of IP intelligence or any other classification engine. This dos feature is through your config definitions. Adding IP intelligence, however, is a good thing in my opinion. I encourage you to look at it as more than just ASM.

Two huge new features in ASM are the ability to define methods per URL and support websockets per URL. In previous versions, methods were globally defined for an application. This is great news. For apps that might have only one page that support a POST, you can define it only for that page.

Websockets are new altogether. Websocket protocol allows client and server to stream data bidirectionally indefinitely. Websockets create a connection over HTTP, but then switch to a single TCP connection using message frames. This allows full duplex and low latency transport. Chances are you used these in your last internet chat. When you think of what could be hiding in one of those, protection really matters.

The last feature I want to mention is the ability for ASM to automatically detect and configure login pages in your application. If you have spent time parsing through someone else’s code to define a login page, you will welcome this feature. Now, that alone would be cool, but if you defined policy settings for brute force and session tracking, it will automatically add those options to the login forms it creates. This is a rockstar feature!

These are some of the main features ASM received in 12.0 and 12.1. There are still others like improved policy building, reduced policy building resource consumption, etc. Once again, if you have not reviewed the release notes, you should. I hope this generates a little interest in seeing what ASM has to offer now, and that you continue to find success in using F5 Networks Application Security Manager.

If you don’t already have ASM, consider what ASM can do for you. If you are already a Guidepoint Security customer and want to know more, reach out to your representative. If you are not a customer and would like to learn more, please feel free to contact us. We have several ASM certified engineers to answer your questions. For more information, email info@guidepointsecurity.com.

About GuidePoint Security
GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

F5 Networks’ ASM: Secure Your Applications, Don’t Give Away Your Kingdom

It occurred to me while I was writing another blog that we need to talk about Web Application Firewalls (WAF). We think everyone should use one. Your current network and security infrastructure is the castle and drawbridge, whereas WAF is your portcullis. Not securing your applications is like giving away the keys to your kingdom.

What is a WAF?

WAFs are the first and last line of defense for your application. A WAF takes over at layer 4 of the Open Systems Interconnection (OSI) model, moves up to layer 7, and looks at the request, response, and payload. It validates data and the package it’s carried in, and its authenticity. In essence, a WAF applies a set of security rules to all aspects of an HTTP conversation.

The difference from your next-generation firewalls (NGFW) and IDS/IPS units, which only inspect packet-by-packet, is that a WAF digs into HTTP content and conversations, and validates the content request, response, and payload against white and black lists. Using predefined signatures or behavioral baselines, the WAF takes appropriate countermeasures based on configured policy elements. WAFs also include enhanced logging, alerting, connection intermediation, and even content manipulation to mitigate the impacts of attacks, mislead attackers, or inject content designed to raise confidence levels for WAF detection mechanisms.

A WAF validates traffic and payloads by learning the way the application should work, prevents bad input or manipulations, and prevents dangerous query/responses. A WAF maintains HTTP RFC compliance on all aspects of the session, and enforces session rules and session flows. It is a multifaceted tool.

F5 Networks Application Security Manager (ASM), in my opinion, is the right tool for the job. It is a tool that complements the F5 Global Traffic Manager (GTM) and Local Traffic Manager (LTM) devices you already use. To illustrate this, let us look at the traffic flow.

First, the GTM picks up the DNS request. Utilizing GTM, you can create a high-speed query frontend with DNS Express and can secure that zone with DNSSEC. GTM also evaluates your DNS request and traffic-shapes your response based on a host of criteria and settings, sending your session on to the network.

Sure, you have a firewall at your internet edge. It might even be next-gen, performs packet inspection, and has some signatures to eliminate some bad traffic. The same might also be true of your IPS/IDS, but these are packet-by-packet inspections and not the whole HTTP conversation (for the most part) and bad traffic gets by.

Here is where the F5 picks up and starts defending. LTM gets the traffic first and blocks malicious IPs, sorts out countries you may or may not want, defends against DDoS, and mitigates ciphers that are too weak or broken, all while restricting IP/port/landing page. LTM also traffic shapes it handoff to the next level, ASM.

ASM starts slow and builds in levels based on policy. It receives that traffic and checks if it matches the defined site. Then it checks to see if it is a new session. From there, it starts checking everything. It checks against signatures, RFC compliance, session-tracking info, methods, request timing, number of requests, header information, etc. And this is only the initial request. We haven’t even gotten to response!

ASM comes with quick-start policy templates for a ton of popular application templates like Exchange, Sharepoint, PeopleSoft, SAP, etc. If one of those doesn’t fit your build, ASM ships with an auto-policy builder. Fire this up and you turn your ASM device into Sherlock Holmes. It watches traffic pass through and automatically starts writing its own suggestions. When those suggestions get enough hits, ASM makes them into policy. The longer it runs, the better the policy.

If you change the application or add to it, it automatically picks that up and starts the building piece again. You can even build policy without affecting users. By keeping it out of blocking mode, you can mature the policy and reduce the likelihood that false alarms will create negative impact for users.

The ASM comes with other cool features, too, such as preventing forceful browsing, where attackers try to gain access to pages not part of the site that might have admin access. You can keep users from bookmarking deep into the app and redirect them to login pages you defined first to define flow. This keeps the application more secure and enables the organization to track sessions to support security, problem resolution, and compliance use-cases.

With this information, you can restrict application access to secondary login pages or other admin-related content by enforcing application flows and protect against webscraping. Brute force protection will even keep those login pages safe by adding a layer of protection including limiting login attempts, identifying automated attacks and more for these critical security entry points for the application.

DataGuard is an awesome feature as well. It protects sensitive fields like credit card numbers, Social Security numbers, and other administrator-defined sensitive data from passing through clear text. Instead, it utilizes masking to overwrite these values in responses with ‘****’. ASM will also mask these in the logs so you don’t have to worry about admins having access to that info as well.

There are so many other features, including signatures and security responses for common web application security threats such as cross-site request forgery (CSRF), cross-site scripting (XSS), clickjacking, cookie manipulation, etc. Any of these topics, as well as the mechanisms ASM utilizes to protect against them, would be worthy of their own blog post.  

I hope this blog has sparked a little more interest in your traffic and maybe even a hard look into the available security measures you can take. If you are already a Guidepoint Security customer, reach out to your representative to learn more. If you are not a customer and would like to learn more, please feel free to reach out to us. We have several ASM certified engineers to answer your questions. For more information, email info@guidepointsecurity.com.

About GuidePoint Security
GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Use Cases Demonstrate How F5 Analytics Can Increase Visibility Into Your Applications

In a previous blog post, I introduced you to F5 Analytics and how it can enable you to gain more visibility into your F5 application delivery controller infrastructure. (If you missed part one, you can check it out here.) This blog post continues where I left off and provides two more exciting use cases for you to explore.

Viewing application page load times

This is a ground-breaking feature that really makes F5 stand out from its competition. Basically, this information is useful for tracking user experience by displaying how long it takes for your application web pages to load on client-side browsers.

Client-side browsers must meet the following requirements:

  • Support navigation timing by W3C
  • Accept cookies from visited application sites
  • Enable JavaScript® for the visited application sites

The BIG-IP Client Side Performance Monitoring (CSPM) feature generates the page load time data. According to F5 Networks, “To calculate the client-side load time for a web resource, the CSPM feature injects a piece of JavaScript code into the HTTP response that it sends to the client. When the client browser executes the JavaScript, it calculates the specific timing values needed by the CSPM feature, and reports those values back to the BIG-IP system in a cookie.”

There are three requirements for CSPM injection in an HTTP response. They are:

  • HTTP content is not compressed
  • HTTP content-type is text/html
  • HTTP content contains an HTML <head> tag

Application page load times are viewable in the F5 Analytics charts. Alerts are configured there as well. Page load time is measured by how long in milliseconds it takes for an end-user to make a request for a web page until the web page finishes loading on the client-side browser. Think of how amazing this is! You’re literally reaching out to your end-user, wherever he or she may be, and gathering statistics of their experience just by enabling a checkbox.

Troubleshooting applications by capturing traffic

This is typically used only for troubleshooting an active issue. I don’t recommend setting this up and leaving it on for eternity. This is not traffic capture like a tcpdump would do, but more of a layer-seven-type capture. I’ll explain that later.

The information captured is stored locally or remotely via syslog or a SIEM, like Splunk. If captured locally, the system stores the first 1,000 transactions. If using a VIPRION system, the system stores the first 1,000 transactions times the number of blades in the system. I recommend capturing the transactions remotely to syslog or Splunk where you are only limited by the storage of the remote destination.

So, what did I mean by layer-seven-type capture? Well, instead of capturing raw data like a tcpdump would, you can capture actual traffic, such as requests, responses, or both. The data contained by those may include:

  • None
  • Headers
  • Body
  • All

You can configure a traffic filter for captured traffic to include filtering by:

  • Virtual servers
  • Nodes
  • Response status codes
  • HTTP methods
  • URL
  • User agent
  • Client IP addresses
  • Request containing string
  • Response containing string

As you can see, this is different than doing a tcpdump and exporting to Wireshark for analysis, which may be fine for certain cases. My point here is to show you a new tool that you can use for troubleshooting an issue with your F5 BIG-IP application delivery controller environment that may rapidly provide you with more relevant data to solve an issue.

I hope this post stimulates your interest in F5 Analytics. It is a powerful (and free) tool to use in your F5 BIG-IP application delivery controller infrastructure.

In addition to F5 Analytics, there are many features available with F5’s application delivery controllers that can enhance your investment, increase your return on investment, and improve end-user experience. If you would like to learn more, GuidePoint’s security professionals have years of experience with F5 application delivery controllers, as well as integrating them with other solutions. We can help you develop a customized security plan to best meet your organization’s needs.

If you’re a GuidePoint client and have questions about F5 Analytics, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization wants to learn more about F5 Analytics and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification is  with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Extending Your Security Infrastructure to Include DNS

For years, F5 has been a key player in DNS with its BIG-IP Global Traffic Manager (GTM). Today, F5 continues the development that has made it an industry leader, focusing on GTM, making it feature-rich, and renaming it BIG-IP DNS. Now through the BIG-IP DNS product you can add speed, reliability, and security to your DNS infrastructure improving both your end-user experience and your company security stance.

Global availability is still an important feature for BIG-IP DNS, but serving and protecting your DNS infrastructure has also taken center stage within this module.

BIG-IP DNS is a proxy like Local Traffic Manager (LTM), but it only services DNS. It consumes incoming DNS queries, parses the request against its configuration, or sends the request on to another server. Like LTM, BIG-IP DNS leverages purpose-built hardware to enhance, accelerate, and secure your DNS service. BIG-IP also offers flexibility and scalability for small to large companies protecting against surges and sudden growth.

On the front line, BIG-IP DNS protects against DNS DDOS by answering queries faster than most traditional DNS installs. Most BIND installs tap out at about 50,000 requests per second (RPS). A good DNS install provides in the neighborhood of 200,000 to 250,000 RPS. A BIG-IP DNS appliance can handle 10,000,000. Add in geolocation and/or IP intelligence, and you can selectively answer queries based on IP, city, state, country, region etc. Deploy BIG-IP DNS in an active sync group and sleep better at night.

Once BIG-IP DNS sorts through incoming queries, it can safely and efficiently address requests.  This is where DNS Cache, DNS Express, and DNSSEC come into play

DNS caching is the initial level for increased DNS performance. BIG-IP DNS can be a transparent cache for your existing infrastructure, adding single point of control and reducing administration overhead. Since you won’t need to run a cache engine on each individual server, this frees up more resources and reduces load on DNS servers. BIG-IP DNS also decreases lookup times by using purpose-built hardware and serving records from memory. This decreases response times and increases end user experience.

In my opinion, DNS Express™ is the highlight feature of BIG-IP DNS. In a nutshell, DNS Express sets up a virtual DNS server in RAM, transfers your DNS zone into it, and provides high speed queries to all of your records. It does this by pulling in new records created in your infrastructure and constantly checking in with the DNS Master just like a secondary server.

DNS Express acts authoritatively for this zone and has unhandled query functions. DNS Express also handles Zone transfers and can be secured using TSIG keys. Additionally, it handles both IPv4 and IPv6 traffic. A key benefit to this is it runs only a subset of BIND, so it’s not susceptible to most vulnerabilities and makes your install even more secure.

If more security is requested or required, BIG-IP DNS supports DNSSEC. This nifty little industry standard allows signing of DNS responses and protections against things like cache poisoning and phishing. It does this by using zone signing keys and, yes, they can be HSM keys.

The signing key setup can be made to automatically roll over based on user-defined thresholds. This adds even more security. Both of these apply to the key-signing keys as well. You can run the HSM locally, in appliances, or offload to a network-based model. Lastly, performance is not an issue here since you use purpose-built hardware for the DNS piece and the keys stored locally.

Overall, BIG-IP DNS goes a long way to filling a strong security role in your infrastructure. For those of you using ‘Better’ or ‘Best’ licensing models, you should have the needed licensing to utilize these capabilities today. If you have an older SKU for GTM, you may need add-on licenses for these features.

GuidePoint’s team of professionals can review your use case and speak to you regarding your solution options. We have several F5 Certified Technology Specialists in GTM to assist you and can help you maximize your installs potential and secure your resources.

If you’re a GuidePoint client and have questions about BIG-IP DNS, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization is interested in learning more about BIG-IP DNS and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

OneConnect: Saving Resources, Increasing Investment

In a previous blog post, I talked about some common Local Traffic Manager (LTM) features that get overlooked, which can easily increase security posture. In this post, I want to discuss one of the less-known features that is frequently neglected because you may not understand the benefits. This feature is OneConnect.

OneConnect is an awesome addition to any modern application that follows good code and RFC standards such as TCP or HTTP. OneConnect creates a pool of first time TCP connections to each pool member and makes them available for reuse by later connections. This is done by using TCP standards like idle timeouts, keepalives, etc.

When an initial connection is created to a pool member, the BIG-IP holds that connection open and uses it for other TCP flows that are destined for that member. This can drastically reduce the number of connections the web server has to process and allocate resources for, thereby improving the web server’s overall performance.

With an HTTP connection, OneConnect can manage HTTP connection flows and process them much the same way as TCP flows. It first manages the TCP flow for that connection like a TCP app. Because OneConnect is HTTP-aware, thanks to whichever HTTP profile you associated with the virtual server, it can read the HTTP flows and process state for them at the same time. If the TCP connection the HTTP flow was using ages out, when a new TCP flow is connected, it will continue that HTTP flow over the new TCP connection.

The LTM uses HTTP standards like keepalives to maintain state. In the case of non-HTTP/1.1 connections, there is no keepalive and the LTM will intercept “Connection:close headers” and transform them to “x-connection: close headers” so it can process connections the same way. This feature, OneConnect Transformations, has to be enabled in the HTTP profile.

By default, OneConnect makes every connection it processes available for reuse. You can restrict this in your OneConnect profile by changing the subnet mask. The subnet mask sets the groupings that OneConnect will make with the incoming IPs.

For example, maybe you don’t want external client IPs and internal client IPs sharing connections. In this case, you could change the mask to 255.0.0.0 so that your 192’s or 10’s will not mix with 25s or 100s. Of course, if you are using 172.16.x.x internally, you need to use 255.255.0.0 instead. Knowledge of your internal IP structure and your application requirements is important.

A note on SNAT: If you use SNAT Automap on your virtual server, OneConnect gets applied after SNAT; so no matter what your mask is, every flow will be reused regardless of the setting in the OneConnect profile. If you use a SNAT Pool, you could use a 32-bit mask to create more flows, but unless you have a really high connection count, there is no need to do this.

To help illustrate this, here is an example I worked on not long ago. One of the state governments I worked with had a web application that processed healthcare options for “Obamacare.” Day-to-day connections to the application hovered at about 4,000 to each server. When it came time for open enrollment, all of the web servers fell over trying to process more than 25,000 connections each. Users who got connected reported the server was so slow, it could not respond to page requests, and timed out. Once OneConnect was enabled with a default mask, the number of active connections dropped to about a 100 per server! The application bounced back completely, and the developers said the application worked better than in development.

There are some special considerations when utilizing OneConnect within your environment. The application has to use TCP standards for clearly defined flows. OneConnect will not work if your flows do not provide good headers for distinguishing source and destination. If your application is 20-years-old and home-grown, it might not work. Recent applications should not have issues.

Secondly, you are sharing TCP flows. If you are sniffing the wire to look at incoming web server traffic, you might not see the flow you are looking for because it was part of a reuse pool. In this case, try to match the client port. The port should remain the same most of the time, but since you are combining different flows from different IPs, the likelihood of overlap is higher. Also, if your application needs to see client IPs, you will need to enable “x-forward-for” and configure the web server to look at that header instead. Additionally, if you are doing SSL Passthru, this is not an option due to the traffic encryption. OneConnect requires termination. You would have to decrypt and then re-encrypt to the backend.

Lastly, one item of particular note is sizing. Since OneConnect can drastically mask a connection table, you need to incorporate the application’s client activity in with the web server connection load to get a feel for how many web servers you need. You might, over time, find out that you cannot turn OneConnect off because your load will be too much for the existing number of web servers you have.

I hope this post has piqued your interest in OneConnect and what your F5 LTM can do for you. There are many additional features beyond “load balancing” that can enhance your investment, increase your return on investment, and improve end-user experience. GuidePoint Security’s professionals, with years of multifaceted expertise, can meet with you to learn more about your organization’s requirements and help build a customized security plan to best meet your needs.

If you’re a GuidePoint client and have questions about OneConnect, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization is interested in learning more about OneConnect and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

From Cyber Analysts to Cyber Hunters: GuidePoint Security Expert to Speak at Anomali Detect

Are you ready to go from your regular job as a cyber analyst to a full-fledged cyber hunter? Join GuidePoint Security at Anomali Detect Sept. 11-13, 2016, at the Westin Washington, D.C. City Center, for a special presentation, “Cyber Hunters: Operationalizing Threat Intelligence for Cyber Analysts.”

GuidePoint Security is a Gold sponsor for the conference, and Matt Keller, our vice president of federal services, will lead a session about how analysts in Security Operation Centers (SOC) can evolve from a detection and response team to proactive cyber hunters who seek out threats before damage occurs.

Matt’s presentation will be from 3:10-4 p.m. Tuesday, Sept. 13, in room National C. He will talk about how to utilize threat feeds to reduce the amount of time it takes to identify incidents and help you plan for responses within the “Cyber Golden Hour.” He will share insight on how your security team can identify threats in real time, moving from cyber analysts to full-fledged cyber hunters.

We’ll also have a table top display set up during Anomali Detect, so be sure to stop by and view a demonstration on our Virtual Security Operations Center (vSOC). By using the cloud to provide dynamic scalability and cost savings, our vSOC analysts can provide validated security incidents so your team can focus on remediation.

For more information about Anomali Detect, visit https://www.anomali.com/anomali-detect. To register for the conference, click here.

For more information about our vSOC and how we can help protect your organization from insider threats, visit www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cybersecurity solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: http://www.guidepointsecurity.com.

10 Steps to Optimize Your F5 Local Traffic Manager Implementation

The F5 BigIP is a great network tool for both functionality and security. F5 leads the Application Delivery Controller market and has been placed in the Leaders Quadrant by Gartner for 9 consecutive years. However, no matter how capable any product is, poor implementations can dramatically reduce your return on investment (ROI), and F5 is no different. Together, we can prevent some of the common mistakes seen repeatedly in just about every install. Below are some simple things you can do to make your install more secure and effective.

1. Round Robin and Load Balancing Methods. Let’s start out with an easy one, load balancing. This is the namesake of today’s Application Delivery Controllers (ADC). Sounds easy, right? Yet more often than not, I see the default option set, Round Robin. It’s not even a real load balancing mechanism. In the broad sense of load balancing, it does spread first time connections out, but it does not balance them.

Load balancing is, and should be, just that, balancing the connection load. In order to do so, you have to maintain a record or a table of the connections you are handling and you have to make an intelligent decision based on those records. Round Robin does not do this. It simply selects the next pool member, in sequence, and continues on despite whether the connections are long or short lived, or persisted, or not. This means that over time, connections can stack up on a server by means of attrition and their random nature.

There are many better load balancing methods to choose from. I like Least Sessions. It’s a constant check against the connection table every time a new connection comes in and it checks against a second table that monitors persisted connections that have not yet timed out. Best of both worlds are had here. Least Connections is good too, but it just checks the connection table. If you reuse backend servers frequently for “similar” applications, you could utilize something “node” based, but I prefer “member” selections because they tend be more application service oriented.

When I say similar, I’m talking about a webserver hosting a dozen of the same or similar websites, like portal pages or home pages, all on different listening ports. I’m not talking about a server running Outlook Web Access (OWA) on one port, PeopleSoft on a second, and FTP on a third. Be reasonable. The expectations for each app/service need to jive for node selection to be of use.

“But I want to use cookie persistence,” you say. That means you have a connection table, but no persistence table. How does that work with Least Sessions? It doesn’t. Since the nature of the cookie is persistence offloaded from the BigIP to the browser, this is a problem. If you are going to use cookie persistence, there are a couple things you should also do as well to help with balancing that load.

a. Use Least Connections as your load balancing method. It will manage the new connections as they come in, but will ignore the ones with a cookie already.
b. For Cookie Persistence, try to use the JSESSION cookie if the app sets one. If the Application sets a different session cookie consistently, use that one. There are canned iRules all over DevCentral for this. Pick one; insert the cookie name into it; they work great and you are done.
c. If you must use the Local Traffic Manager (LTM) cookie instead, make sure it is NOT a session cookie. Expire them. Set the expiration to whatever the Applications timeout is. If the application doesn’t have one, set something reasonable like 15 minutes. The smaller the window, the better. This is about load, security, and user expectation. If a user walks away from their machine for roughly 15 minutes, the machine should have implemented a screensaver with a lock, right? The users already expect this. The expectation that the Application would have logged them out for security reasons should be there as well. Nurture that perception.
d. Lastly, TCP timeouts should be aggressive. The default is 5 minutes. These will close stale TCP sessions to both the client and the server and will help reduce connection load. Yes, I did not mention oneconnect, that’s another discussion entirely.

2. SSH and HTTP Allowed list. This one is actually easy and should go without saying. More often than not, I see this missed during setup. Restrict what IPs or IP Ranges can connect to the management functions of the BigIP. Make them only allowable from your internal subnets. Better still, make them the IP Ranges assigned to the subnets your admins utilize for management purposes. If you use jumpboxes, use those IPs. Just remember to allow all of the BigIP’s MGMT ports to talk to each other too.

SSH can be set during the initial GUI install portion of the build and can be accessed anytime after by selecting System>Platform>SSH Allow.

For whatever reason, the HTTPD list, or the admin gui, if you prefer, is managed by TMSH and can be done so by implementing: tmsh modify /sys httpd allow add { <IP address or IP address range> }

3. Port Lockdown. This is another security feature that works in conjunction with the allow lists. By default, any interface IP you assign to a BigIP, allows it to talk to the network. Pretty straightforward. Did you know, that this also means each IP is a way to connect to the admin gui, or to access the cmd line?

Enter Port Lockdown. This feature allows you complete control over what MGMT functions are allowed PER IP. You do need a little bit of knowledge here, but it’s still pretty easy. When you define an IP on the LTM, if it faces clients or the Internet, set Port Lockdown to Allow None. If it faces the servers or other BigIP devices, set it to Allow Default. None means zero; no MGMT functions at all. Default means allow iQuery, 443, SNMP, SSH, DNS, OSPF, and CAP, which is network failover. This assumes you trust the Internal IPs. If you do not, than you are using Allow Custom and have to know what you need on each IP. Personally, I always use Allow Custom. I assume you should know if the IP you are assigning is facing the SNMP server, or GTM, or another BigIP. Remember, settings on the self-IPs and Floating IPs need to match!

As an update to this, in version 12.0, BigIPs, set this to Allow None.

4. Default Cookies. These are used for Persistence but actually are a security feature too. Every time you make a connection to an LTM Virtual Server with Cookie Persistence enabled and you are proxied to a pool member, you get a session cookie. By default, all BigIP Cookies in the LTM module show up as BIGipServer<pool_name>. It tells the client you are using a BigIP and the pool name you are connecting to, and if they decode the payload, the server IP and its listening port as found in this SOL article here. This can be classified as information disclosure about your install. Encrypt your cookies and their payload and make your install more secure!

Create your own default HTTP and Cookie profile for your install. Use them to encrypt the cookie contents and the cookie itself. Keep in mind these things:

a. Do not use your company name. Vanity here gives away information to a hacker.
b. Do not use the application name. Same here, and this can make things far easier to target as well.
c. The Cookie name should make sense only to you. Generating a random Cookie Name is not a bad idea.
d. Set the Cookie Encryption Use Policy to required in the new Cookie Profile. This will make sure that cookie contents are encrypted.
e. Set a Cookie Passphrase keeping in mind a, b, and, c. I recommend generating a random passphrase and keeping it in a password vault. The passphrase is used as the key in the encryption of the Cookie payload, and should be protected as a sensitive credential.
f. Lastly, when you create the HTTP profile that references the Cookie Profile you just set up, set a new passphrase. Do not use the same passphrase that you used in the Cookie Profile. This should be protected as a sensitive credential too.

For more information on this, reference sol14784: Configuring BIG-IP cookie encryption (10.x – 11.x).

5. Default Profiles. These are not as good as they used to be, especially the TCP profiles. TCP capabilities in BigIP have evolved but the profile settings have remained largely unchanged. If you are using the base TCP profiles, you may be missing out on a lot of free optimization, response time, and most important of all, end user experience improvements. Ever heard of Multipath TCP? Nagel’s Algorithm? How about the TCP Window Scaling described in RFC 1323?

TCP options are really their own topic. Fortunately, for those not in the know, there are several articles from F5 and TCP gurus to help you out on this point. I recommend Stop Using the Base TCP Profile! on DevCentral and these two white papers from the F5 main website: TCP Optimization for Service Providers and Optimize WAN and LAN Application Performance with TCP Express. Also, if you have not already gotten a copy, you may want to consider downloading High Performance Browser Networking. It’s free and a really good read.

These articles break down the TCP features and give you quite a bit of insight into what you can do without having to spend a serious amount of time researching TCP. The best part is that all of these features are built into the stack and are sitting there ready to do their thing. Making these changes on one side is usually enough to reap the benefits because of TCP’s negotiation.

6. SSL Decryption. I see the lack of this a lot, and it boggles my mind. If you went through the trouble of buying and installing an F5 BigIP, why would you not terminate SSL on it? It is purpose built and hardware accelerated to handle that traffic. Plus, removing that SSL load from the server processing those transactions means more resources for whatever application is running on it. And since you would be sending clear text to the server, securely intercepting and monitoring that traffic becomes easier. You want to inspect the traffic on the LTM and make intelligent decisions with it; iRules, Policies, pool selection, root redirects, stream expressions, etc., all rely on inspection of traffic.

You might say you need SSL on the server for the application to function properly or for Authentication reasons. Well, you have two options then. First, you can re-encrypt to the back end servers, throwing up a server profile on your Virtual Server. This usually works fine, and you get to do all those other cool traffic decisions I mentioned, but you might need to add an iRule for passing along Client Certificates. Or secondly, you could use Proxy SSL, which essentially creates a channel from the client to the backend server passing on the client Auth mechanism to the server while allowing the F5 to still do its thing as a proxy. Application Security Manager (ASM), the F5 Web Application Firewall (WAF) product, works great with this too.

7. HTTP Server Header. This is another one of those security things. This one might take a bit of “know your application” sense. The Server Header is a little used field with the purpose of information disclosure and fingerprinting the server. It’s there to help out the Hackers by telling them what application you are using and which version they need to hack!

Okay, that’s not really what it’s there for. RFC 2616 for HTTP 1.1 says ‘product tokens are used to allow communicating applications to identify themselves by software name and version.’ Basically, it’s a mechanism in the HTTP standard to allow the client side of a HTTP stream to verify applications and/or versions of the server for security reasons. No one uses it. Best to make it go away.

Here’s the issue with the LTM, though. It actually inserts this field when it does certain things like 302 redirects. So, if you are going to make this go away, you are going to have to add an iRule or some of its logic if you already have an iRule assigned. Here’s a good one from DevCentral. Or, you could add ASM and utilize all the security benefits a WAF provides.

8. Cipher Strings. I would be remiss if I did not mention this when talking about security features. There are many versions of BigIP running out there and practically each version has a different set of ciphers. I do not expect you to know them all. I do expect you to know what your version does though. I also expect that you at least learned what a cipher is, what it’s for, and what it’s made up of. That said, here’s some help.

a. sol13156: SSL ciphers used in the default SSL profiles (11.x – 12.x)
b. sol13171: Configuring the cipher strength for SSL profiles (11.x)
c. https://f5.com/Portals/1/Premium/Architectures/RA-SSL-Everywhere-deployment-guide.pdf
d. www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Server_Protocol_and_Cipher_Configuration
e. www.feistyduck.com/books/openssl-cookbook/

F5 is touchy about these. They will not make recommendations on cipher strings unless there is an outright security issue with a particular cipher. They typically just give suggestions or examples. Invest some time here and get to know the “what’s” and “how’s”. You need to know what you don’t know. Read the F5 stuff, then the openssl, and such. Don’t think for a minute that the defaults are going to be fine. Vulnerabilities and attack techniques such as Poodle, Heartbleed, and Logjam are getting more and more common it seems, and weaknesses in ciphersuites such as RC4 continue to create issues for otherwise “secure” web applications.

As a note, if you start your install with the creation of a new “default” client SSL profile, you can then set it as the parent for all of the individual profiles you will create later. Then, when something like RC4 pops up, you can make the change in that parent and it filters down to the others. Powerful, but handle with care.

9. LTM Denial Of Service. I mention this one as a suggestion. LTMs do some pretty cool things right out of the box on DOS Protection like SYN Cookies. Some simple configuration tweaks add a bit more coverage. While not a comprehensive solution or a replacement for adding in ASM, an IDS/IPS, firewall, etc., it’s free with the product. Why not use it?

a. https://devcentral.f5.com/questions/ddos-attack-prevention-in-ltm
b. https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_dos.html
c. https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14813.html

10. IP Intelligence. It’s a cheap little security feature you can buy for the LTM and other modules that really makes sense. It’s an IP reputation database that updates constantly over the Internet to an F5 Partner. The database contains a list of suspicious and known bad IPs from across the Internet that you do not want to access your install. It costs about as much as a yearly certificate renewal for a single website, but this can be leveraged for every website on that LTM.

F5 even supplies two neat little iRules you can use or modify as needed, and are located here. I highly recommend adding this even if you are not doing anything with GEOLOCATION on the F5. But if you are, don’t just block the bad countries, cities, whatever. Block the BAD IPs in the countries you are allowing.

Tony Turner, Practice Lead for Application Delivery, recently hosted a webinar about how application delivery technologies can help support availability, optimization, management, overall security and more. Please click here to view the webcast.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: http://www.guidepointsecurity.com.

Lobotomy | The Android Assessment Toolkit

Through the years of assessing and reverse engineering Android applications, I consistently found a number of manual tasks overwhelmingly tedious and, at times, in desperate need of automation. I repeatedly found efficiency issues while working through my methodology for assessing Android applications, having to bounce from tool to tool in order to accomplish a specific goal. However, an idea that had been festering in the back of my mind for a while finally found its way into code, thus, Lobotomy was created.

Lobotomy, a new Android security toolkit, was developed to serve multiple purposes. The first objective was to build a framework that could easily be used to add in new features or functionality that would solve certain tasks when hacking up and reverse engineering Android applications. This was created on the notion that you will load once and work forever, meaning you can load your target Android application and work on the innards of that application through different modules without having to switch to other tools to perform operations on the same application. Another purpose of the framework was to become a wrapper for other well-known tools and their features sets.

Some of the tools Lobotomy provides wrappers for include:

• apktool
• bowser
• Dex2Jar
• Androguard
• Frida
• Adb

Perhaps the most important aspect of Lobotomy is its ability to find the important functionality and vulnerabilities within any target application quickly. There are many features that help motivate someone to look at the material that really matters. Whether that is an exported Broadcast Receiver, or the instrumentation of the Activity lifecycle, Lobotomy also helps minimize the amount of time spent looking at unnecessary components as well.

Features

Here are some of Lobotomy’s current features:

• APK loader
• APK Decompilation with apktool
• Conversion magic with Dex2Jar
• Attack surface enumeration
• Component enumeration
• Permission enumeration
• Permission to API mappings (BETA)
• Convert any APK into a debuggable APK
• APK Profiler
• Bowser | parseUri, loadUrl, addJavascriptInterface search and destroy
• Web services and frontend UI
• Logcat wrapper
• Frida implementation (BETA)
• SurgicalAPI | Find API usage for common vulnerabilities in targeted methods

Lobotomy is evolving as it continues to be developed by GuidePoint Security. We would love your help and input with the new features.

You can check out Lobotomy here:

https://github.com/guidepointsecurity/lobotomy

We will also be adding a Wiki to document all of the features and how to use them, as well as a list of new and upcoming features in the works for the tool.

About GuidePoint Security
GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

POODLE: SSL 3.0 Fallback Vulnerability

Overview

The SSL version 3.0 POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability (CVE-2014-3566) was officially released on October 14, 2014 by OpenSSL. The flaw was disclosed by a team of Google researchers including Bodo Möller, Thai Duong, and Krzysztof Kotowicz. This vulnerability is a consequence of an implementation flaw associated with the use of block cipher encryption in SSLv3. Block ciphers encrypt data in fixed-length blocks. If the plain text value to be encrypted is not a multiple of the defined block size, the cipher will apply padding to the data to increase the size, so that it can be converted to cipher text. The concern is that the Message Authentication Code (MAC) does not cover the block cipher padding and when the message is decrypted, the integrity of the padding cannot be verified. This can allow an attacker to decrypt cipher text, one byte at a time.

This vulnerability only affects the SSLv3 protocol, which is rarely used by modern web browsers that prefer the usage of TLSv1 encryption. However, due to the widespread support for SSLv3 on both servers and web browsers, an attacker can still leverage this vulnerability by using it in conjunction with a downgrade attack. A downgrade attack could be accomplished by intercepting and manipulating traffic associated with the SSL/TLS cipher suite negotiation, conducted between the client and server.

In the original disclosure article, B.Möller, T. Duong, and K. Kotowicz succinctly illustrate the impact of this vulnerability, referencing a scenario in which it could be used to compromise secure session tokens within the context of a web application (p.2, https://www.openssl.org/~bodo/ssl-poodle.pdf).

“In the web setting, this SSL 3.0 weakness can be exploited by a man-in-the-middle attacker to decrypt “secure” HTTP cookies, using techniques from the BEAST attack [BEAST]. To launch the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), run a JavaScript agent on evil.com (or on http://example.com) to get the victim’s browser to send cookie-bearing HTTPS requests to https://example.com, and intercept and modify the SSL records sent by the browser in such a way that there’s a non-negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.”

An attacker could inject the JavaScript agent in a persistent or even reflected Cross-Site-Scripting (XSS) attack, or inject this code within the context of an established Man-in-the-Middle attack. This could be used to cause the victim’s browser to send the attacker cookie bearing HTTPS requests; which, in turn, can be modified and, if accepted by the server, could allow the attacker to decrypt the cookie, one byte at a time.

Impact

Due to the fact that this vulnerability must be exploited within a chosen-plaintext context, the only probable exploitation scenario with any significant impact is within a web context. For an attacker to successfully exploit this vulnerability, multiple highly specific conditions must exist. These conditions include the following:

  • The attacker must be able to intercept and manipulate traffic between the client and server (as in a Man-in-the-Middle scenario)
  • The attacker must be able to execute custom JavaScript code to initiate multiple crafted requests within the context of the victim’s browser

Despite the special circumstances and high level of skill required to exploit this vulnerability, the impact of a successful attack would be significant. Successful exploitation could result in an attacker gaining access to small pieces of highly sensitive encrypted traffic such as session tokens. Acquisition of these session tokens could be used in session hijacking attacks to completely take over a victim’s session within the context of the web application.

Identification

Server Identification

Server Testing with OpenSSL Client:

To determine if a particular service is vulnerable, use the SSL client in SSLv3 mode and supply the server name or IP address in conjunction with the port number of the service in question. If the connection succeeds then SSLv3 is enabled:

Syntax:
openssl s_client -connect <server>:<port> -ssl3

Example:
openssl s_client -connect google.com:443 -ssl3

Server Testing with Nmap:

The SSL-enum Nmap Scripting Engine (NSE) script can also be used to determine if servers are vulnerable. Nmap should be executed with the syntax provided below:

Syntax:
nmap <server> –script ssl-enum-ciphers -p <port>

Example:
nmap google.com –script ssl-enum-ciphers -p 443

If the scan returns a list of support ciphers under the SSLv3 header, then SSLv3 is enabled.

SSLv3:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA – strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA – strong
|       TLS_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA – strong
|       TLS_RSA_WITH_RC4_128_MD5 – strong
|       TLS_RSA_WITH_RC4_128_SHA – strong
|     compressors:
|       NULL

Server Testing with SSLLabs:

Qualys has made a web-based testing utility available at the URL listed below. This can be used to test public facing servers.

https://www.ssllabs.com/ssltest

If the scan returns indication that there is still support for SSLv3, then the server is vulnerable.

poodle 1

Client Identification

Browser Client Testing with Poodle Test:

A web-based test has been constructed to test client browsers and determine if they are vulnerable to the POODLE attack.

https://www.poodletest.com/

If your browser is vulnerable, the site will display the following image:

poodle 2

Remediation

Unfortunately, there is no patch remediation for this vulnerability. However, SSLv3 is a depreciated protocol and should be disabled on both servers and clients (browsers). Further, both Mozilla and Google have posted that they will be updating both FireFox and Google Chrome, in the coming months, to disable SSLv3 support. However, it should be noted that disabling SSLv3 could potentially break some websites or legacy web applications that support SSLv3.

Browser Remediation

Remediation on Microsoft Internet Explorer:

Click the Settings button at the top-right corner of the browser, and then select ‘Internet Options’. Then browse to the ‘Advanced’ tab. In the Settings menu, scroll to the bottom and uncheck the box labeled ‘Use SSL 3.0’. Once completed, click ‘Apply’ then ‘OK’.
poodle 3

Remediation on Mozilla FireFox:

In the URL address bar, browse to ‘about:config’. You will then be given a warning, indicating that you should only modify these settings if you know what you are doing. We do, so click the button to disregard the warning and proceed. Then, in the Search bar, type ‘security.tls.version.min’. Double-click the setting with that Preference Name and then change the integer value from 0 to 1. Once this change has been made, click ‘OK’. This will disable SSLv2 and SSLv3, and only allow the browser to support TLSv1 and later.

poodle 4

Remediation on Google Chrome:

Ironically, despite the fact that it was a Google team that identified this vulnerability, Chrome’s GUI management interface offers no option to disable support for SSLv3. A common workaround is to start Chrome from a shortcut that leverages the command line argument to disable support for SSLv3.

To do this, right-click your Google Chrome shortcut and select ‘Properties’. Then, append the command line argument ‘ –ssl-version-min=tls1’ to the end of the value in the Target field (as seen in the provided image). Click ‘Apply’ and then ‘OK’. Once this modification has been made, support for any versions prior to TLSv1 is disabled anytime the browser is started from this Shortcut.

poodle 5

Server Remediation

Remediation on Apache Server:

Modify the SSLProtocol directive in the server’s ssl.conf file to disable support for versions earlier than TLSv1 on Apache. The location of this file may vary depending on the build of the server.

For Ubuntu, the file can be modified with:

sudo nano /etc/apache2/mods-available/ssl.conf

If mod-ssl is enabled, the location will be:

sudo nano /etc/apache2/mods-enabled/ssl.conf

For CentOS, the file can be modified with:

sudo nano /etc/httpd/conf.d/ssl.conf

In the configuration file, modify the SSLProtocol directive to include the following:

SSLProtocol All -SSLv2 -SSLv3

To verify the configuration change, use the following:

apachectl configtest

Once support for SSLv2 and SSLv3 has been disabled, the Apache service will need to be restarted. This can be done with the following command:

sudo service apache2 restart

Remediation on IIS:

To disable support for SSLv3 on Microsoft IIS, a registry tweak is required. Open the registry editor (with command ‘regedit’) and then browse to the following key:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\

Inside the Protocols key, there should be a key called ‘SSL 3.0’ and inside that key, there should be a key called ‘Server’. If these keys do not exist, create them. Then, inside the ‘Server’ key, create a DWORD value called ‘Enabled’ and then leave its value at 0 (default). Once completed, restart the server to implement the new changes.

poodle 6

Remediation on NGINX:

Modify the ssl_protocols directive in the nginx.conf file to disable support for versions earlier than TLSv1 on Nginx. This file is located at /etc/nginx/nginx.conf and can be modified with:

sudo nano /etc/nginx/nginx.conf

Modify the ssl_protocols directive in the file to include the following:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

To verify the configuration change, use the following:

sudo nginx -t

Once support for SSLv2 and SSLv3 has been disabled, the nginx service will need to be restarted. This can be done with the following command:

sudo service nginx restart

What is TLS_FALLBACK_SCSV?

In the event that you are not prepared to disable the use of SSLv3, downgrade attacks can be alternatively mitigated in some distinct scenarios by using a browser that supports a new cipher suite value called TLS_FALLBACK_SCSV. In the event that both the server and client browser support this option, a more secure negotiation process is used that prevents downgrading to a protocol or cipher that is less secure than the highest mutually supported option.

Unfortunately, at this time, limited support on the server-side and limited adoption by client browsers has made this an ineffective, comprehensive solution for this problem.

Presently, TLS_FALLBACK_SCSV is only supported by Google Chrome 33.0.1750 (February 2014 Build) and later. Other major web browsers will likely adopt support in the following months.

 References

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

The 3 Largest Security Breaches of 2014

From streamlining business processes to connecting people globally, the Internet has undoubtedly improved lives, but it has also brought about a massive number of risks for which many organizations are often unprepared. As a result, data breaches across a large variety of industries all over the world have practically become commonplace.

Ranked in terms of the largest amount of data stolen, here are the top three security breaches of 2014 thus far:

1) Russian Data Breach by “CyberVor”

Hold Security revealed on August 5 that a Russian cyber-gang they named “CyberVor” pilfered billions of records from international organizations and individuals alike. 4.5 billion records to be exact.

CyberVor’s attack mainly targeted login credentials, according to Hold Security’s summary of the incident. The gang obtained credentials from fellow hackers on the black market at first, but upped the ante when they began utilizing botnets. CyberVor was able to use botnets to identify SQL injection vulnerabilities among the sites of their choosing, and then use those vulnerabilities to steal larger quantities of personal information—such as email addresses and passwords—from the databases of their victims.

2) eBay

In late February to early March, unknown attackers gained access to a handful of eBay’s employee credentials, which ultimately provided them access to a database of customer data. The database included names, encrypted passwords, phone numbers, physical and email addresses, and other non-financial data.

Luckily for customers, the company stated in a blog post on May 21 that they had not yet seen any signs of unauthorized user activity or compromised financial information. It is estimated that a majority of the company’s 145 million customers were affected, but the exact number is still unclear. Regardless, eBay decided to err on the side of caution and alert all of its customers to change their passwords.

3) Home Depot

On September 1, Home Depot confirmed that hackers had gotten a hold of an estimated 60 million credit card numbers over the course of approximately five months. Surprisingly, the company was not the first to mention the breach to the public. Instead, it was Brian Krebs, an information security buff who let the world know, resulting in a class action lawsuit in Georgia against Home Depot, Inc.

The Home Depot stores that were compromised are located in the United States and Canada, according to Paula Drake, a company spokeswoman. This means that any customer of these 2,157 stores could have been affected. On the bright side, online shoppers are not affected, and no debit card PINs were stolen.

So, how do other companies avoid making the same mistakes? They can start with requiring 2-factor authentication for all Internet facing systems. Further assuring that basic security tools, such as Anti-Malware, are regularly updated and appropriately deployed can prevent the spread of known malicious software for a low cost. Finally, the combination of strong logging, a SIEM, and a vigilant SOC place a good defense when security technologies fail and require an organization to respond quickly.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.