HTTP Brute Force Mitigation Playbook: Slow Brute Force Protection Using Behavioural DOS - Chapter 6
Brute Force attack is where attacker tries to find the password of users quickly, there are times when attacker is not in hurry and do make his attack go under the radar, using very slow brute force attack.It can not be detected by detection criteria of Brute force protection feature of Advanced WAF/ASM reason being if you try to tweak the setting to catch slow brute force attack then its very hard for ASM/Advance WAF to distinguish between attack and legitimate user login atttempt. We may use other protection available in ASM/Advance WAF to protect from Slow brute force attack. In this chapter to protect from Slow brute force attack we will use TLS signature generated by behavioural DOS. But first: Benefits, Limitation and Requirement. Benefits Benefit of using TLS fingerprint: Good and bad Clients can be differentiated based on SSL handshake. Once the Advance WAF/ASM is 100% confident user does not have to do anything to find out unusual/attack traffic pattern. This can be also used to protect mobile application as it does not use Javascript. Limitations To get TLS fingerprinting signature using BADOS legitimate traffic should be learned by Advanced WAF/ASM On ASM, Behavioural DOS can be configured on max 2 virtual servers, where as on Advanced WAF, Although there is no license limitation of attaching DOS profile with BADOS enable to Virtual server but it is not recommended to configure more then 70 BADOS enabled Virtual server per box. Requirements ASM/Advanced WAF license. Appropriate rights to access/make changes from GUI and command line. Some of the reporting is available only if AFM is provisioned in addition to the above mentioned modules. (If AFM is not provisioned you can still find the information using CLI) Proactiveness As a general rule, instead of waiting for attack and then take necessary action, We should always be proactive in defending attack. Preparation for mitigating slow Brute force attack. Slow brute force is very hard to detect, So most important thing to protect application from slow brute force attack is Advanced WAF/ASM should know the normal traffic. For that we can use Behavioral & Stress-based (D)DoS Detection option under DoS Protection profile of Advance WAF/ASM. For Configuring DoS Protection profile, to protect against slow brute force attack using TLS fingerprinting follow the below mentioned steps. Important:For BIG-IP ASM/Advance WAF 14.1.0, you can access theTLS fingerprinting signaturesconfiguration sectiononly when you had previously selectedUse Legacy Application Dos viewin theHTTP Propertiesconfiguration pop-up. Go to Security››DOS Protection ›› Protection Profiles››click create. Enter the profile name as per your requirement, select the family as HTTP and press Commit Changes to System Click on newly shown HTTP and then click configure settings for HTTP Family settings. Next click on Use Legacy Application DOS View Go to Behavioral and stress-based detection under Application security. Change operation mode to blocking and Threshold mode to automatic. Under Behavioral Detection and Mitigation enable Request signature detection along with TLS fingerprinting signatures and Use approved signatures only (In case you don’t want to use unapproved signature). Leave all the settings unchanged and click save and finished. (Make Sure Bad actors behavior detection is unchecked as we want to use TLS signature) Select Mitigation to Standard or as per requirement from available options and then Click save Next apply the newly created dos profile to the appropriate https virtual server. Go toLocal Traffic>Virtual Servers. Select the name of the HTTPSvirtual server. Go toSecuritytab and selectPolicies. ForDoS Protection Profile, selectEnabled. ForProfile, select the DoS profile created in above steps. Select theUpdatebutton. Let the normal traffic pass through the VS. This will allow ASM to learn the traffic. How do we know ASM is ready and is 100% confident about the normal traffic? Login to cli of BIGIP Run command “admd -s vs./Common/<VSname>+/Common/<DOSprofilename.info.learning>” For exampleadmd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning You will see output as similar to the one mentioned below. vs./Common/BF-Test+/Common/Brute-Force-test.info.learning:[0, 0, 0, 0] Once the traffic starts passing through vs these values will increase. Each value has its own meaning as described below. A.baseline_learning_confidence: Description: in % how confident the system is in the baseline learning. Desired Value: > 90% B. learned_bins_count: Description: number of learned bins Desired Value: > 0 C. good_table_size: Description: number of learned requests Desired Value: > 2000 D. good_table_confidence: Description: how confident, as %, the system is in the good table Desired Value: Must be 100 for signatures You may run the command again if the Behavioral DoS is still learning Still learning admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning Behavioural DOS feature is based on learning analysing all traffic to the web application, building baselines, and then identifying anomalies when server stress is detected.So its important to know when server is stress and how to check the server street level. To find out the stress level Go to Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) Find out the VS for which you would like to check the status and Click the arrow below Attack status. Once you click you will detailed informed is displayed on the screen, which includes Server Stress To check the Server stress using CLI you may run below mentioned command. admd -s vs./Common/<VSname>+/Common/<DOSprofilename.sig.health> Server Stress value Range: If there is no traffic server value is 0.5 If server functions properly value is between (0,1) Value higher then 1 is considered as load and mitigation may be applied for example admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.sig.health Once the output of below command shows appropriate values (as mentioned above) which tells ASM is confident, ASM is ready to differentiate between normal and attack traffic. Below output shows ASM is 100% confident admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning Slow brute Force attack has been reported To check the status of attack and Server stress level. Go to Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) Find out the VS for which you would like to check the status and Click the arrow below Attack status. Once you click you will see detailed informed is displayed on the screen. For example as show below Server Stress is 100 now. If AFM is not provisioned you may run below mentioned command to check if the server is under stress. admd -s vs./Common/<VSname>+/Common/<DOSprofilename.sig.health> Server Stress value Range: If there is no traffic server value is 0.5 If server functions properly value is between (0,1) Value higher then 1 is considered as load and mitigation may be applied For example admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.sig.health You may continue to monitor the output using command line or GUI to find out if attack has started. To check if attack has started you may check using command line. If the value is 0,0 then there is no attack if the value is 1 VS is under attack admd -s vs./Common/<VSname>+/Common/<DOSprofilename.info> for example: admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info Using the GUI Go to Security››DoS Protection:Protected Objects Note: (To get this view AFM should be provisioned ) If you continue to monitor you may notice that BADOs has started generating signature. But accuracy in start will not be 100% and it may take some time to become 100% accurate. Using CLI admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info Using GUI Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) If the Dynamic Signature status is unready the signature is not ready and does not have 100% accuracy. Note: (To get this view AFM should be provisioned, If AFM is not provisioned you may continue monitor using CLI ) Once signature is ready Dynamic signature status will change as shown below. Note: (To get this view AFM should be provisioned, If AFM is not provisioned you may continue monitor using CLI ) Once the signature’s accuracy is 100%, It will be available underSecurity››DoS Protection:Signatures >> Dynamic. As shown below. You may notice in above screenshot that Accuracy of signature is 100% where as approval status is Unapproved, If you want to use only approved signature (which we have used in this case) you need to click the check box infront of the signature, as soon as you will enable check box a window on right side will pop up and you may enable check box in-front of Approved and then press update to manually approve the signature. Note: User approved signatures only under Behavioral & Stress-based (D)DoS Detection in the DOS profile should be enable. Once you approve the signature, Signature approval state will change to manually approved as shown below You may also check DOS logs by checking Security››Event Logs››DoS›› Application Events Another Graphical view option for DOS can be checked by going to Security››Reporting:DoS:Dashboard If you want to check a specific attack ID then please on right side under Attack IDs find the attack ID and click on it. As soon as you will click on it page will show the data related to specific attack ID as shown below. As shown above during attack, TLS signature generate by Behavioural DOS ismitigating the attack and normal requests are still passing through using Behavioural attack signature. Note: By default, when the systemidentifies signature pattern anomalies, itsilently drops the connection. You can change the mitigation mode and force the system to send a reset(RST) when the traffic matches a signature pattern. To change the mitigation mode fromdrop to reset, perform the following steps: 1. Log in to tmsh by typing the following command: tmsh 2. To change themitigation mode to reset, typethe following command: modify sys db adm.mitigation.accelerated.signatures.drop.mode value reset Note: If you want to generate HTTP signature using BADOS instead of TLS signature in DOS protection profile you can select accelerated signature and rest of the steps will remain same.Lightboard Lessons: Explaining the GitHub DDoS Attack
On Feb 28, 2018 the popular website GitHub was the victim of the largest Distributed Denial of Service (DDoS) attack in recorded history. The attackers used open memcached servers to launch an amplification attack that pushedtraffic at the rate of 1.35 Tbps. Fortunately, GitHub was prepared with a DDoS scrubbing service and was able to mitigate the attack, and the attackers stopped after about 20 minutes. The unfortunate part, though, is that many thousands of open memcached servers are still out there on the Internet and could be used for a similar attack at any time. Watch the video below to learn about the details of the attack and the mitigation steps. Related Resources: F5 Labs Analysis of the GitHub DDoS Attack F5 Silverline DDoS Protection ServicesThe BIG-IP Application Security Manager Part 4: Attack Signatures
This is the fourth article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first three articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs This fourth article in the series will discuss attack signatures...what they are, why they are necessary, and how you can use them to protect your environment. What Is An Attack Signature? Attack signatures are rules and patterns that identify attacks against your web application. When the ASM receives a client request (or a server response), the system compares the request/response to the attack signature associated with your security policy. If a matching pattern is detected, the ASM will trigger an "attack signature detected" violation and will either alarm or block based on the enforcement mode of your security policy. For example, a SQL injection attack signature will look for certain expressions like ' or 1=1 and if a user enters that string into a field (i.e. the username field) on your web application, the ASM will block the request based on the SQL injection attempt. An ideal security policy would include only the attack signatures needed to defend your application. If too many are included, you waste resources on keeping up with signatures that you don't need. Likewise, if you don't include enough, you might let an attack compromise your application without every knowing it. BIG-IP Attack Signatures The BIG-IP ASM comes loaded with over 4,500 attack signatures, so it's certainly capable of protecting just about any attack your application might encounter. The following screenshot shows a sample of the ASM attack signatures. You can view this entire list by navigating to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature List. You can also create your own unique signatures and use them to protect your application as well. It can be overwhelming to figure out which signatures to employ for your application...especially when you have over 4,500 to choose from! That's where the Attack Signature Sets can help out. I know everyone read my ASM article on Policy Building, so you'll remember the part about choosing the attack signatures for your application. This is the part where you need to know what systems your application is built on (Windows, SQL, IIS, etc) so that you can choose the appropriate settings for the attack signatures. Once you do this, the ASM automatically configures an Attack Signature Set for your security policy. You can view this by navigating to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature Sets. The following screenshot shows the specific attack signature set for the security policy that protects the online auction site that I've been using recently. Notice that, when I was building the security policy for this application, I chose Unix/Linux, Apache, Apache Tomcat, PHP, and MySQL as the assigned systems for the application. Based on those choices, the ASM automatically assigned the correct attack signatures to my security policy. That way, I didn't have to pick and choose from the long list of 4,500+ attack signatures...the ASM did it for me! One more thing before we show some of this stuff in action. If you notice that a specific attack signature is causing some problems for you (false positives, etc), then you can disable that individual attack signature in your policy. Navigate to Security >> Application Security >> Attack Signatures >> Attack Signature List. Then, you can click on "Show Filter Details" and search for the specific attack signature that you want to disable. When you find it, simply click on it and then uncheck the "Enabled" box. After you do this, that specific attack signature will be disabled for that specific security policy, but it won't be affected in other security policies. This is a good thing because you may need that same attack signature in other security policies on your BIG-IP ASM! The Attack In this quick example, I tested to see if the online auction site would let me conduct a Cross Site Scripting (XSS) attack. I navigated to the "Sell an item" page and then, instead of describing the item, I inserted a small script in the description block of the page. The script simply pops up an alert screen with a message. If this worked, I knew that I could do some other nasty XSS attacks against this application. So, let's check it out... Here's what happened when I finished filling out everything on the page... So, the attack worked. As a hacker, I would be thrilled to know that I have a way to attack this site, but as a security guy, I would be very nervous about the vulnerability of my application. BIG-IP Interface Let's take a quick look at the ASM interface and see where we can dive into the details of this attack. You can navigate to Security >> Event Logs >> Application >> Requests and review all the application requests. The following screenshot shows the details of the attack listed above. I clicked on the request at the top of the list and it loaded up all the details of the request. Notice that this request was marked "Legal" and "Informational" because I don't have the attack signatures configured to block yet. If you look toward the bottom of the page, you'll notice a Violation entry that says "Attack signature detected". I clicked on this link and it pulled up the smaller window shown in the screenshot below...this outlines the exact attack signatures that triggered the violation. You'll notice that each attack signature has a unique Signature ID, so you can search, filter, etc if you ever need to look up that attack signature again. Also, notice that the "Alarm" column states that these three attack signatures are in staging...that's the reason the ASM didn't block the XSS attack. More on that in just a minute. The last thing to note is that you can click on the "View details" link in the right-most column of each attack signature. This will pop up another window that gives you all the details on why that specific attack signature triggered a violation. So, I clicked on the first attack signature in the list above (XSS script tag (Parameter) with Signature ID 200000098) and it pulled up the following window. This shows the exact detail of what caused the violation. In this case, check out the "Detected Keywords" block at the bottom of the page. You should notice that the keyword (highlighted in red with a box around it) is part of the actual XSS script that I used in the attack on the application. That keyword is what triggered the attack signature. You can use this information (as well as other information found in these windows) to make security decisions about your policy and application. It's a good idea to review your security logs on a regular basis to make sure you see these types of requests coming in! Since the ASM allowed the XSS attack to access the application, let's go back and make sure the attack signatures are configured correctly to block this behavior in the future. Navigate to Security >> Application Security >> Attack Signatures >> Attack Signatures Configuration and uncheck the Signature Staging Enabled box. This will take all the attack signatures out of staging and will allow them to start taking the actions listed in the boxes to the right of each listed signature set. In the screenshot below, I have the Generic Detection Signatures (which are listed in every security policy by default) as well as my system specific signature set that was created when I built the security policy. For each of these signature sets, I have "Learn, Alarm, and Block" enabled. This means that the ASM will continue to generate learning suggestions for the policy, it will alarm (log) each attack violation, and finally it will actually block the attack. By the way, after I took the attack signatures out of staging, I tried the XSS attack again...guess what happened? Signature Updates The last thing to discuss in this article is Signature Updates. As you can imagine, network attacks are very dynamic and require constant attention. In order to keep up with the ever-changing attack world, the signatures you employ in your security policy need to stay up to date as well. The BIG-IP ASM has a Signature Update feature that will add/delete attack signatures as needed. You can set the ASM to update signatures on a schedule (daily, weekly, or monthly) or you can update them manually. You can check out all the options when you go to Security >> Options >> Application Security >> Attack Signatures >> Attack Signatures Update. The last thing I'll mention is that all new attack signatures are automatically placed in staging. This happens because you won't know how a new attack signature is going to affect your application until you've had some time to test it first. After you test the new signature(s), then you can take them out of staging and turn them loose to protect your application! Well, that's it for the attack signature article. Make sure you come back next time for some fun with XML security! By the way, here's a link to the chapter on Attack Signatures from the BIG-IP ASM Configuration Guide: http://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/config_guide_asm_10_2_0/asm_attack_sigs.html. If you have more detailed questions, you might find some good info there as well. Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
Mitigating sslsqueeze and other no-crypto, brute force SSL handshake attacks
I’ve spent a bunch of cycles lately trying to analyze how resistant we are to a new class of SSL handshake attacks. You see, I have a thing for these weird, asymmetric crypto attacks. To this day, the SSL Renegotiation DDoS piece is still the most popular article of mine, partly because the obsessiveness passion comes through in the writing. The Classic SSL Renegotiation Attack The original SSL renegotiation attack tool, by the French group “The Hacker’s Choice”, repeatedly requested SSL handshakes with a vulnerable server. These handshakes were ten times more CPU-intensive for the server than they were for the attack client. The BIG-IP SSL stack has become increasingly resistant to the tool; the latest versions of BIG-IP automatically reject clients that attempt to send multiple renegotiations in a single connection (no iRule needed). A new class of handshake attack tools There’s a new class of SSL attacks tools - one could call them “No Crypto” attack tools. These new attack tools boost the computational asymmetry between the client and the server to a 2 nd order multiplier by vastly reducing the client workload. Basically, the new attack clients don’t do any crypto at all – they just send pre-canned packets that look like an SSL handshake but aren’t. In his excellent analysis of handshake attacks, Vincent Bernat writes about these much more efficient attack tools. “With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on [in his analysis] may just be ineffective.” One of these tools is called sslsqueeze and is written by none other than Michal Trojnar, the author of stunnel (the original SSL tunnel utility). Thankfully the tool isn’t widely available, but I was able to get a copy of the source. The sslsqueeze code is super tight. It is structured in such a way as to be almost entirely I/O-bound, so it is extremely lean with regard to the CPU. Here it is throwing over a thousand handshakes a second against an Apache server using about 2% of the client CPU. Each "success" means that the Apache server went to all the trouble to try to decrypt a bunch of junk and then returned "bad-record-mac" each time. Frankly, I'm impressed that an Apache server can turn around that many 2048-bit decrypts without hardware offload. That's what four cores will get you; each one doing about 300 decrypts per second (and little else). After letting it run for a minute, the time command shows that sslsqueeze is nearly entirely I/O-bound. Not CPU-bound, which is what we expect since it's not doing any real crypto. sslsqueeze real 1m3.514s user 0m4.264s sys 0m7.904s This is a single client, using almost none of its own CPU, keeping all four cores on a web server busy. Can sslsqueeze overwhelm cryptographic accelerators? Next I ran sslsqueeze against a real, physical BIG-IP with cryptographic offload accelerators. I keep a BIG-IP 3900 at my house for just these kinds of cases where we need to see how the underlying Cavium cryptographic accelerators respond. This platform does not represent state-of-the-art hardware, but the BIG-IP 3900 remains one of the most widely-deployed F5 appliance models to-date. See all those failures? That's because BIG-IP is returning record-overflow instead of bad-record-mac which is what sslsqueeze is expecting. The effect is really the same though. The 3900's crypto card is only rated for about 3000 SSL TPS (with 2K keys). The sslsqueeze program (on a single client!) is basically consuming all of that capacity without even really trying. The modern equivalent of the 3900 is the 4200v, which is rated for 9000 TPS. The attack client computer that I bought for $200 at a used computer store can generate upwards of 20,000 (!!!) fake handshakes per second. That’s not good. Not good at all. If even cryptographic processors can’t absorb the attack, how can you stop sslsqueeze? Disabling SSL Renegotiation doesn’t help During the original SSL renegotiation attack analysis, simply disabling renegotiation was sufficient to foil that attack. In fact, most servers were disabling renegotiation at the time to avoid a completely different vulnerability. However, disabling renegotiation has no effect in this case. The sslsqueeze tool is so efficient that it doesn’t need to multiplex SSL handshakes through a single TCP connection. It simply opens a new TCP connection, sends its junk, waits for a response and then closes the connection. iRules to the rescue once again If disabling renegotiation doesn’t work and cipher selection doesn’t help and virtual server rate-limits don’t apply, what is left? After exhausting all the options available in the BIG-IP 11.5 native SSL implementation, and still unable to effectively mitigate sslsqueeze, I turned to iRules. As a colleague of mine likes to say, iRules make the difficult tasks easy and the impossible tasks merely difficult. In other words, when all else fails, you can always write an iRule. iRule #1 – ssl_hx_rlimit Here’s an iRule I had some fun putting together – ssl_hx_rlimit (SSL handshake rate limit). It’s a nice, clean iRule that has the following benefits: Very small chance of false positives. Minimal performance degradation (not measurable in my setup). Minimal memory requirements (just one state variable per client address). Not signature based – should catch all kinds of handshake monkey business. Probably the biggest issue with this iRule will involve so-called mega-proxies or giant NATs where thousands of individual clients appear to come from the same IP (think AOL or other service provider). If an attacker is hiding behind one of these mega-proxies, then iRule #2 (see below) will have to be used instead. The full iRule and it’s commentary can be found on this DevCentral page:ssl_hx_rlimit iRule iRule #2 – sslsqueeze_rx As stated above, the ssl_hx_rlimit iRule won’t really work if the attacker is mixing their bogus requests in with other valid requests from the same mega-proxy.There may also be other pathological cases as well where the ssl_hx_rlimit fails and you just need a quick fix to throw in place. iRule #2, sslsqueeze_rx, is that quick fix. It has these benefits: Extremely fast. No additional memory requirements. Can handle the mega-proxy cases But also this main drawback: Very easy for an attacker to change the attack signature. sslsqueeze_rx works because the sslsqueeze tool sends the exact same ClientHello every time. Therefore, all a signature-based system has to do is look for this incoming packet and block the connection. If the attacker changes the ClientHello at all then you’d have to modify the static::sxch to represent the new signature. A determined attacker would be including random data in the 32 bytes of random data anyway. You could still key off the three specific ciphers that sslsqueeze is sending if you needed to. The full iRule and it’s commentary can be found on this DevCentral page:sslsqueeze_rx iRule Long Term Fixes in TLS? The IETF TLS working group has taken a look at this problem recently and there is a proposal for a much more elegant fix than dropping or rate limiting. Enter “Client Puzzles”. There is a proposed draft for to ask the client to perform some kind of crypto puzzle to prove that it is a real TLS client and not some hack tool. It reduces the asymmetry by putting an arbitrary load on the client. When I had told a colleague about this problem he said “instead of puzzle, could you have the client perform some Bitcoin block chain verification instead?” We discussed this option at the TLS meeting, but decided that it would lead to too much “gaming” on behalf of malicious servers, heheh. http://tools.ietf.org/html/draft-nir-tls-puzzles-00 The puzzles would very likely be based on this trick. · Server chooses a random number. · Computes SHA hash for it. · Asks client “which number, in this range, hashes to this value?” You can increase the work done by the client by simply increasing the size of the range hint (keyspace). Making it “stateless” like a SYN cookie is a little trickier but could be done. The client puzzle solution remains an interesting idea at this point with no real plans to be included in the handshake for TLS 1.3. Another possible mitigator is the fact that the TLS protocol is slowly switching toward elliptic-curve key exchanges that are more balanced in terms of client versus server CPU load. This proposal is before the IETF committee right now for TLS 1.3. It is my hope that this will reduce the threat scope for these so-called “no crypto” attacks. Conclusion As I write this, attackers are still attacking the applications rather than the TLS servers themselves. Typically the attackers will find a large PDF file or an expensive database query and then they’ll just open TLS connections and request those URIs repeatedly. We stop those attacks with the web application firewall. Internet Engineering Task Force drops RSA from next SSL standard (TLS 1.3) http://t.co/BCw64n4yFY via @kennwhite < wow! @rmhrisk — David Holmes (@dholmesf5) May 4, 2014 As more web application firewalls get deployed and caching gets better and better, the attackers may start switching to TLS protocol attacks. Until TLS 1.3 gets adopted broadly supported you may find your SSL site under assault from one of these new attack tools. And if that happens, hopefully you’ll be able to defend your application with one of these two iRules. Let me know if you see an attack, or if you see ways to improve upon these iRules.A Decade of Breaches
Whales Not Included Being from the Hawaiian Islands, the annual gathering of the Kohola (humpback whales) is always a spectacular view. They can get over half their body out of the water and administer a cannonball body slam splash like you've never seen before. Most of the internet thinks they breach to either see what's up (so to speak), let other whales know they are around (if the haunting squeal isn't doing it) and most common, to relieve the body of lice, parasites and barnacles. While nature's breaches are unmatched, many internet security breaches are run of the mill leakages. The Verizon 2014 Data Breach Investigation Report (DBIR) found that over the last 10 years, 92% of the 100,000 security incidents analyzed can be traced to nine basic attack patterns. The patterns identified are: Miscellaneous errors like sending an email to the wrong person Crimeware (malware aimed at gaining control of systems) Insider/privilege misuse Physical theft or loss Web app attacks Denial of service attacks Cyberespionage Point-of-sale intrusions Payment card skimmers The really cool thing about the 9 attack patterns is that Verizon has also charted the frequency of incident classification patterns per industry vertical. For instance, in financial services 75% of the incidents come from web application attacks, DDoS and card skimming while retail, restaurants and hotels need to worry about point-of-sale intrusions. Utilities and manufacturing on the other hand get hit with cyber-espionage. Overall across all industries, only three threat patterns cover 72 percent of the security incidents in any industry. Once again, no one is immune from a breach and while media coverage often focuses on the big whales, the bad guys are not targeting organizations because of who they are but because a vulnerability was found and the crooks decided to see if they could get more. This means that companies are not doing some of the basics to stay protected. For the 2014 analysis, there were 1,367 confirmed data breaches and 63,437 security incidents from 50 global companies. For the most part, the fixes are fairly basic: Use strong authentication, patch vulnerabilities quickly and encrypt devices that contain sensitive information. I've barely scratched the surface of the report and highly suggest a through reading. ps Related Verizon 2014 Data Breach Investigations Report Identifies More Focused, Effective Way to Fight Cyberthreats Verizon Data Breach Investigations Report Verizon's data breach report: Point-of-sale, Web app attacks take center stage DBIR: Poor Patching, Weak Credtials Open Door To Data Breaches Bricks (Thru the Window) and Mortar (Rounds) Surfing the Surveys: Cloud, Security and those Pesky Breaches Targets of Opportunity Unplug Everything! Photo: Protected Resouces Division, Southwest Fisheries Science Center, La Jolla, California. Technorati Tags: f5,dbir,breach,attack,cyber,verizon,ddos,security,silva Connect with Peter: Connect with F5:
