Archive for compliance

The OWASP Top 10 - 2017 vs. BIG-IP ASM

Posted in security, f5, big-ip, application security, asm, compliance, malware, 0day, owasp by psilva on November 29th, 2017

With the release of the new 2017 Edition of the OWASP Top 10, we wanted to give a quick rundown of how BIG-IP ASM can mitigate these vulnerabilities.

First, here's how the 2013 edition compares to 2017.



And how BIG-IP ASM mitigates the vulnerabilities.



BIG-IP ASM Controls


Injection Flaws

Attack signatures

Meta character restrictions

Parameter value length restrictions


Broken Authentication and Session Management

Brute Force protection

Session tracking

HTTP cookie protection


Sensitive Data Exposure

Data Guard


XML External Entities (XXE)

Attack signatures (see below)


Broken Access Control

File types


URL flows

Session tracking

URL flows

Attack signatures (Directory traversal)


Security Misconfiguration

Attack Signatures


Cross-site Scripting (XSS)

Attack signatures

Parameter meta characters

Parameter value length restrictions

Parameter type definitions (such as integer)


Insecure Deserialization

Attack Signatures (see below)


Using components with known vulnerabilities

Attack Signatures integration


Insufficient Logging and Monitoring

BIG-IP ASM can help with the monitoring process to detect, alarm and deter attacks


Specifically, we have attack signatures for “A4:2017-XML External Entities (XXE)”:

  • 200018018           External entity injection attempt
  • 200018030           XML External Entity (XXE) injection attempt (Content)

Also, XXE attack could be mitigated by XML profile, by disabling DTDs (and of course enabling the “Malformed XML data” violation):


For “A8:2017-Insecure Deserialization” we have many signatures, which usually include the name “serialization” or “serialized object”, like:

  • 200004188           PHP object serialization injection attempt (Parameter)
  • 200003425           Java Base64 serialized object - java/lang/Runtime (Parameter)
  • 200004282           Node.js Serialized Object Remote Code Execution (Parameter)

A quick run-down thanks to some of our security folks.



Prevent a Spoof of an X-Forwarded-For Request with BIG-IP

Posted in security, f5, big-ip, application security, http, compliance, scams, devcentral, infrastructure by psilva on October 24th, 2017

Last week, we looked at how to do Selective Compression on BIG-IP with a local traffic policy so this week let’s try something security related using the same procedures.

You can associate a BIG-IP local traffic policy to prevent a spoof of an x-forwarded-for request. This is where bad actors might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP system.


  • We’re using BIG-IP v12 and,
  • We already have a Virtual Server configured to manage HTTP traffic with an HTTP profile assigned to it.

Let’s log into a BIG-IP


The first thing we’ll need to do is create a draft policy. On the main menu select Local Traffic>Policies>Policy List and then the Create or + button.


This takes us to the create policy config screen. Type a unique Policy Name like PreventSpoofOfXFF and optionally, add a description. Leave the Strategy at the default of Execute First matching rule. Click Create Policy.


We’re then directed to the draft policy’s General Properties page and here we can create the rules for the policy. In the Rules area, click Create.


We’ll give the rule a unique name like, StopSpoof and the first condition we need to configure is to match all HTTP traffic with the matching strategy. This means we can use the default setting of All Traffic. Then we’ll tell the policy what to do when the All Traffic condition matches. The new action is to Replace the http header named X-forwarded-for with the value of tcl:[IP::client_addr] (to return the client IP address of the connection) at the request time. Click Save.


Also, save the draft.


And then select the box next to the draft policy and click Publish.


We can now associate the published policy with a virtual server that we’re using to manage http traffic. On the main menu click Local Traffic>Virtual Servers>Virtual Server List and click the name of the virtual server you’d like to associate for the policy.


On the menu bar click Resources and next to Policies click Manage.


Move PreventSpoofOfXFF to the Enabled list and click Finished.


Now, the virtual server with the PreventSpoofOfXFF local traffic policy will prevent any HTTP traffic that attempts to spoof an x-forwarded-for request.

Congrats! You’ve easily added additional security to your local traffic policy! You can also watch the full video demo thanks to our TechPubs team.


Managing Your Vulnerabilities

Posted in f5, big-ip, application security, cloud computing, compliance, 0day by psilva on December 9th, 2016


I recently recovered from ACDF surgery where they remove a herniated or degenerative disc in the neck and fuse the cervical bones above and below the disk. My body had a huge vulnerability where one good shove or fender bender could have ruptured my spinal cord. I had some items removed and added some hardware and now my risk of injury is greatly reduced.

Breaches are occurring at a record pace, botnets are consuming IoT devices and bandwidth, and the cloud is becoming a de-facto standard for many companies. Vulnerabilities are often found at the intersection of all three of these trends, so vulnerability and risk management has never been a greater or more critical challenge for organizations.

Vulnerabilities come in all shapes and sizes but one thing that stays constant – at least in computer security - is that a vulnerability is a weakness which allows an attacker to reduce a system’s information assurance. It is the intersection where a system is susceptible to a flaw; whether an attacker can access that flaw; and whether an attacker can exploit that flaw within the system. For F5, it means an issue that results in a confidentiality, integrity, or availability impact of an F5 device by an unauthorized source. Something that affects the critical F5 system functions - like passing traffic.

You may be familiar with CVE or Common Vulnerabilities and Exposures. This is a dictionary of publicly known information security vulnerabilities and exposures. Each vulnerability or exposure gets a name or CVE ID and allows organizations to reference it in a public way. It enables data exchange between security products and provides a baseline index point for evaluating coverage of tools and services. MITRE is the organization that assigns CVEs. There are also CVE Numbering Authorities (CNA). Instead of sending a vulnerability to MITRE for numbering, a CNA gets a block of numbers and can assign IDs as needed. The total CVE IDs is around 79,398.

Most organizations are concerned about CVEs and the potential risk if one is present in their environment. This is obviously growing with the daily barrage of hacks, breaches and information leaks. Organizations can uncover vulnerabilities from scanner results; from media coverage like Heartbleed, Shellshock, Poodle and others; or from the various security related standards, compliance or internal processes. The key is that scanning results need to be verified for false positives, hyped vulnerabilities might not be as critical as the headline claims and what the CVE might mean for your compliance or internal management.

For F5, we keep a close eye on any 3rd party code that might be used in our systems. OpenSSL, BIND or MySQL are examples. For any software, there may be bugs or researcher’s reports or even non-CVE vulnerabilities that could compromise the system. Organizations need to understand the applicability, impact and mitigation available.

Simply put: Am I affected? How bad is it? What can I do?

vuln chart

With Applicability, research typically determines if an organization should care about the vulnerability. Things like, is the version of software noted and are you running it. Are you running the vulnerable function within the software? Sometimes older or non-supported versions might be vulnerable but you’ve upgraded to the latest supported code or you are simply not using the vulnerable function at all. The context is also important. Is it being used in default, standard or recommended mode? For instance, many people don’t change the default password of their Wi-Fi device and certain functionality is vulnerable. It gets compromised and becomes part of a botnet. But if the password was changed, as recommended, and it becomes compromised some other way, then that is a different situation to address.

cvss calculator

For Impact, there are a couple ways to decide how bad it is. First, you can look at the severity of the vulnerability - is it low, medium, high or critical. You can also see if there is a Common Vulnerability Scoring System (CVSS) score tied to the vulnerability. The CVSS score can give you a gauge to the overall risk. To go a bit deeper, you can look at the CVSS Vector.

There are 3 sections to the CVSS. There are the constant base metrics covering the exploitability of the issue, the impact that it may have and the scope that it is in. There are the temporal metrics, which may change over time, giving the color commentary of the issue. And there are the environmental metrics which look at the specific, individual environment and how that is impacted. Areas explored here include things like the attack vector and complexity; whether elevated privileges are required or any user interaction along with the scope and how it affects the confidentiality, integrity and availability of the system. One can use the CVSS calculator to help determine a vector score. With a few selections you can get a base, temporal and environmental score to get an overall view of the severity. With this, you can get an understanding as to how to handle the vulnerability. Every organization has different levels of risk based on their unique situation. The vulnerability base score may have a critical listing yet based on your environmental score, the severity and risk may be nil.

Lastly, the Mitigation taken is not an exact science and truly depends on the issue and the organization’s situation. Mitigation is not necessarily prevention. For example, compensating controls, such as restricting root level access might mean that a vulnerability simply isn’t exploitable without a privileged account.

Vulnerability management and information security is about managing risk. Risk analysis, risk management, risk mitigation and what that risk means to the business. Patching a vulnerability can introduce other risks, so the old refrain of “patch your $#!+” is not the panacea we’re often led to believe. Risk is not limited to the severity of the vulnerability alone, but also to the required vector for exploiting that vulnerability where it exists within a specific organization’s infrastructure.

It’s important to understand your risk and focus on the important pieces.


Healthcare in the Crosshairs

Posted in security, f5, silva, identity theft, compliance, medical, healthcare by psilva on April 1st, 2015

Is Healthcare the new Target?


Recently I've received a number of 'I am writing to inform you that we were the target of a sophisticated cyber attack and some of your personal information may have been accessed by the attackers..' letters for myself and my family. I especially hate the ones that start, 'To the parents of...' because my daughter has a rare genetic condition. You probably got one of these letters too since the Anthem breach could have disclosed medical records for as many as 80 million people.

Medical identity theft is big business and has become a huge target over the last few years. The attackers are not really interested in that sprained ankle or those 25 stitches from last summer. They want the personally identifiable information. Names, addresses, birthdays, and social security numbers. Stuff you can actually use to open accounts, commit insurance fraud and create fake identities - using real information. Healthcare info also goes for a premium on black market sites. One expert noted that recently that at one underground auction, a patient medical record sold for $251 while credit cards are selling at .33 cents. With all the recent retail breaches, credit cards have flooded the underground, plus they can get cancelled quickly. I also know that fraudsters are already trying to entice people with fake emails and calls regarding the breaches - I've gotten a bunch of them recently. More than ever, do not click the email link unless you're expecting something.

The interesting phenomenon for me is all the identity theft protection offerings from various credit bureaus. One breach, sign up here...another breach, sign up there. It is important to take advantage of the services to stay alert on your identity but you also have to include the very same sensitive info that was just compromised to yet another entity. I'm waiting on the breach of one of these identity protection sites. I mean the thieves must be thinking, 'well, we missed them in the medical grab but maybe we can get them through the protection app.'

According to Ponemon Institute, about 90% of healthcare organizations have reported at least one data breach over the last two years with most due to employee negligence or system flaws but more, as we've seen recently, are due to criminal behavior. Certainly, there will be more of these healthcare hiccups in the coming years especially with the push to digitize medical records. Great for patient access but a huge risk for unauthorized peeks. With the Premera breach hot on Anthem's heels, I hope providers are getting the message that the bad guys are coming for ya.





Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

The Hacker Will See You Now

More than 1.8 million medical ID theft victims in 2013

That's a 19% increase over last year according to the 2013 Survey on Medical Identity Theft.  More than 300,000 new medical identity theft cases were reported during the one-year period, the study found.  The 4th annual survey, conducted by the Ponemon Institute, defined medical identity theft as a person using an individual's name or personal identity “to fraudulently receive medical service, prescription drugs and goods, including attempts to commit fraudulent billing.”

One of the biggest contributors to the increase was fake or spoofed medical websites and spam emails.  Medical identity theft victims who reported that a cyber schemes caused their troubles doubled from 4% in 2012 to 8% in 2013.  It is clear that the amount and frequency of spear phishing specifically targeting medical ID theft has gone up.  This is not the simple 'Buy this personal enhancement drug here' emails but authentic looking emails from a provider.  You click the malicious link and either malware is installed to your computer or you are directed to a website that looks exactly like your medical provider's and you enter (give away) your credentials there.  You might even be able to log into something that will request you update your personal information.  Perfect, I get your credentials along with some additional Rx information or mailing address or SSN or date of birth anything that I can use to impersonate you.

As far as data breaches as a cause, only 7% (up 1 tick from last year) felt a data breach by their insurer, health care provider or related was linked to the fraud.

A separate but related survey, a new Deloitte report says healthcare organizations are in various stages of mitigating the security risks of medical devices.  These include patient monitors, infusion pumps, ventilators, pacemakers and imaging devices.  Deloitte interviewed the medical device security leaders at nine large hospital systems and they indicated that their organizations have a long way to go and that they need more cooperation from device manufacturers. 

The Food and Drug Administration (FDA) recently released a guidance on the "content of premarket submissions for management of cyber security in medical devices."  The guidance suggested that device makers incorporate security features into their products to limit access to only trusted users, trusted content, and use fail-safe and recovery devices. They want manufacturers to consider threats like hacking, malware and other vulnerabilities of the device's software and to work with providers on addressable scenarios.  This is certainly an area of importance for both providers and the device manufactures.  Remember all the wrangling with PCI and those payment devices?  Granted, the FDA guidance is a recommendation and not a regulation like PCI so there is reluctance to include security measures in purchasing contracts.

The other issue healthcare organizations face is trying to secure older proprietary devices.  These closed systems make it almost impossible to scan for vulnerabilities but they are still in widespread use.  For other devices that run on well know commercial operating systems, they are vulnerable to the same threats that any device with that software has.

Deloitte also asked the medical device security heads where their organizations stood in several areas of cyber security.  These included: organizational leadership, risk framework, identification and evaluation, data flow, vulnerability management, vendor agreements and manufacturer engagement.   Ken Terry over at Information Week goes into detail of each.

So far there have been no documented instances of "intentional threats" to medical devices, according to the report but healthcare providers are not required to report security incidents to the FDA or the device manufacturer unless a death or serious injury has occurred.






Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

World’s Biggest Data Breaches [Infographic]

Cool and disturbing at the same time.  A fully interactive version can be found here where you can click each circle to get more information.   I thought about adding all the numbers but stopped at 140,621,000 between 2012 and 2013.

World's Biggest Data Breaches & Hacks




Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

The Malware Mess

A couple weeks ago McAfee Labs released the McAfee Threats Report: Second Quarter 2013, which found that Android-based malware marked a 35% growth rate not seen since early 2012.  They also found twice as many new ransomware offerings in Q2 as in Q1, bringing the 2013 ransomware count higher than the total found in all previous periods combined.  Everything was in play - SMS stealing bank malware, infected legitimate apps, malicious apps in sheep's clothing, along with fake dating and entertainments apps.  A lot of areas that we spend a good portion of our mobile time.

In addition to mobile threats, Q2 also saw a 16% uptick in suspicious URLs and a 50% increase in digitally-signed malware samples.  Attackers are showing that they can adapt to the criminal opportunities and continue to infiltrate the ever changing infrastructure.  Ransomware, a very popular and profitable scheme, where pop-ups or other messages threaten the user unless they pay a ransom, doubled from Q1 to Q2.  Hey, if it works, might as well.  Malware signed with legitimate certificates increased 50% to 1.2 million samples.  You think you're getting the safe code due to the certificate's authentication but that cozy blanket gets cold quick.  Malware also continues to find life with infected URLs according to McAfee.  The total number of suspect URLs found reached 74.7 million or a 16% increase over Q1.  The Indexed Web is at least 3.82 billion pages so around 2% of the web but still.  I might suggest, 'watch what you type, don't click suspicious links, avoid porn sites,' and other rather obvious actions but these days it could be delivered through an ad loading on a popular news site.  Almost no one is immune.  SPAM continues to hog email servers accounting for almost 70% of all global email volume.  That's nuts.  Think about it all the legitimate email we send over a month and it only accounts for 30% of all email?!?  What a waste of resources.  Other highlights included cyber espionage campaigns and attacks on digital currency.

These threats come at a time where there seems to be a disconnect between executives and their technical teams. 

The Ponemon Institute's most recent research shows that when it comes to locking down enterprise infrastructure, the application layer is responsible for more than 90% of all security vulnerabilities, yet more than 80% of IT security spending continues to be at the network and endpoint layer.  According to Ponemon, 'Most Organizations are Woefully Behind in Application Security.'  For it's 'Current State of Application Security Report' , they asked 642 IT professionals (both executive & engineering) 20 questions concerning tools usage, development team knowledge and security best practices to better understand the maturity of an organization’s application security program in comparison to the core competencies of high-performing organizations.  They found that a much higher percentage of executive-level respondents believe their organizations are following security procedures through the lifecycle of application development than do the engineers who are closest to executing the security processes.  For instance, 71% of executives interviewed believe that application security training is available and up to date but only 20% of technical staff felt the same.  Around 67% of execs feel they have a mature application security program, compared to 33% of technical staff and 75% of executives believe that a secure architecture exists in their organization verses 23% of technical staff.  Someone is either not communicating or many organizations do not yet consider the need to proactively do something about application security or even attempt to understand application security risks.

What is troublesome is that even with all the media attention and the afore mentioned malware stats, most organizations are not building nor testing their applications for security. According to the Ponemon report, only 43% of respondents say they have a process in place to test for vulnerabilities prior to release, and only 41% are using automated scanning tools to test applications during development. And just to pile on, only 42% push their applications to manual penetration testing by internal teams or from a third party. 

So, threats are increasing (I feel like I say this multiple times a year) and it seems that organizations' response to them are decreasing...or at least not taking them seriously enough.  In many ways, it is kinda like the real world.  We think, feel, believe that we're safe until something happens...then we take all the precautions.  Many organizations need to do that yesterday. 

Today's technologies are awesome but every once in a while I do miss 4 TV stations (including PBS), typewriters, rotary phones, mimeograph machines, S&H Green Stamps and the hard wires of yesteryear.




Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

Corporate Mobile Data and BYOD Infographic(s)

Posted in security, silva, privacy, control, mobile, compliance, apple, smartphone, andriod, malware, context, byod by psilva on July 29th, 2013

Very busy week so I figured I'd re-source a couple of recent infographics that I found interesting and timely. 

Mobile Corporate Infographic




Have a great week! 


Connect with Peter: Connect with F5:
o_linkedin[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

Big Data Getting Attention

According to IBM, we generate 2.5 quintillion (2.5 followed by 17 zeros) bytes of data every day.  In the last two years, we've created about 90% of the data we have today.  Almost everything that's 'connected' generates data.  Our mobile devices, social media interactions, online purchases, GPS navigators, digital media, climate sensors and even this blog to name a few, adds to the pile of big data that needs to be processed, analyzed, managed and stored.  And you think that saving all your movies, music and games is a challenge.

This data growth conundrum is 3 (or 4 - depending on who you talk to) dimensional with Volume (always increasing amount of data), Velocity (the speed back and forth) and Variety (all the different types - structured & unstructured).  Veracity (trust and accuracy) is also included in some circles.  With all this data churning, security and privacy only add to the concerns but traditional tactics might not be adequate.

Recently the Cloud Security Alliance (CSA) listed the top 10 security and privacy challenges big data poses to enterprises and what organizations can do about them.  After interviewing CSA members and security-practitioners to draft an initial list of high priority security and privacy problems, studying the published solutions and characterizing problems as challenges if the proposed solution(s) did not cover the problem scenarios, they arrived at the Top 10 Security & Privacy Challenges for Big Data.

They are:

  1. Secure computations in distributed programming frameworks
  2. Security best practices for non-relational data stores
  3. Secure data storage and transactions logs
  4. End-point input validation/filtering
  5. Real-Time Security Monitoring
  6. Scalable and composable privacy-preserving data mining and analytics
  7. Cryptographically enforced data centric security
  8. Granular access control
  9. Granular audits
  10. Data Provenance

The Expanded Top 10 Big Data challenges has evolved from the initial list of challenges to an expanded version that addresses new distinct issues.

  1. Modeling: formalizing a threat model that covers most of the cyber-attack or data-leakage scenarios
  2. Analysis: finding tractable solutions based on the threat model
  3. Implementation: implanting the solution in existing infrastructures

The idea of highlighting these challenges is to bring renewed focus on fortifying big data infrastructures.  The entire CSA Top 10 Big Data Security Challenges report can be downloaded here.



Connect with Peter: Connect with F5:
o_linkedin[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

20,000 For Every 1

On average. 

Earlier this month, the State of California released its first annual data breach report showing that in 2012, 131 data breaches were reported putting more than 2.5 million Californians personal data at risk.  The real kicker is that of the 2.5 million, 1.4 million would have been fine if the companies had simply encrypted the data.  Yup, over half would've been safe if proper care was taken to protect the data.  A bit aggravating isn't it?  With all the basic solutions available and data breach media attention you'd think encryption was a no brainer.  Add to that, if it was scrambled, it wouldn't have even needed to be reported according to state law!  Companies can even avoid data breach lawsuits (in California) for encrypting data.  So many reasons.

Retail had the most intrusions with 26% followed closely by finance and insurance with 23% of the total.  Health care accounted for 15% with education and government both taking 8%.  The remaining 15% represented the ever popular 'other.'  Over half included included compromised social security numbers and 5 involved more than 100,000 citizens. 

Security and computer failures, including skimmed point-of-sale devices, accounted for the majority of the intrusions with outsiders doing the most damage.  Always check those ATMs, gas station pumps, unattended kiosks and other machines you slide with your cards.  Sadly, even with personal diligence, once the company has it, they seemingly still let it roam free.  I guess the good news is the requirement to report the breaches so individuals are aware and can take action.

This is is the first state-based, state-specific review of reported data breaches and the California Attorney General's Office recommends that companies focus on improving the following areas of privacy and security:

  • Encryption - If you have unencrypted personal information, you'll probably be next.
  • Security Training – Review and update security procedures, as well as provide regular training to maintain compliance.
  • Readability of Consumer Breach Notifications – Companies should ensure that recipients actually understand the content of such notices.
  • Offering Credit Monitoring Assistance – When offered to consumers, it can limit future issues.

Hopefully, in the near future other states will release their own reports to better understand their situations in context to the all the yearly, national reports.



Connect with Peter: Connect with F5:
o_linkedin[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

« Older episodes ·