Shellshock – The SIP Proxy Edition
The recent Shellshock and Heartbleed vulnerabilities have something in common – they both affect very infrastructural services. That is the reason their magnitude is much bigger than any other ol’ vulnerability out there. “Everyone” uses bash, “everyone” uses OpenSSL. Shock the shell However, one of the differences is that bash isn’t a public facing service like OpenSSL. Bash is simply the shell service of the underlying operating system. To be able to get to bash and exploit the vulnerability – one has to find a way to remotely “talk” with and feed it their evil commands via environment variables. Arguably, the most common path to reach bash is through a web server that makes use of the CGI technology. By default, CGI creates user-controlled environment variables, which are then parsed by bash, for every HTTP request the server accepts. This means that exploiting bash on such a system is as easy as sending an HTTP request to a CGI controlled page. However, CGI isn’t the only service that uses bash “behind the scenes”. DHCP services are affected, SSH and Telnet are affected, FTP services are affected. Some SIP proxies are also affected, we will learn why and how to mitigate them. SIP Express Router and friends Popular open source SIP proxies, such as Kamailio, have been found vulnerable to Shellshock. The author of a POC tool called sipshock has written a very clear explanation on the matter: The exec module in Kamailio, Opensips and probably every other SER fork passes the received SIP headers as environment variables to the invoking shell. This makes these SIP proxies vulnerable to CVE-2014-6271 (Bash Shellshock). If a proxy is using any of the exec functions and has the 'setvars' parameter set to the default value '1' then by sending SIP messages containing a specially crafted header we can run arbitrary code on the proxy machine. This means that if you have a public facing SIP proxy running a SIP Express Router implementation, you should patch your bash immediately. If you have an F5 LTM doing load balancing for that SIP server – a simple iRule will save you the headache of patching the operating system, and give you breathing room to do so properly. Mitigate Shellshock SIP with BIG-IP iRules The following iRule will detect SIP requests which contain the Shellshock pattern in one of the headers: when CLIENT_DATA { set sCVEPattern "*: () \{*" set bCVEFound 0 if { [string match $sCVEPattern [UDP::payload]] } { set bCVEFound 1 } } when SIP_REQUEST { if { $bCVEFound } { log local0. "Detected CVE-2014-6271 Shellshock attack! IP: '[IP::client_addr]' From: [SIP::from] To: [SIP::to]" reject } } Create a new iRule and attach it to your SIP proxy virtual server. Make sure the Virtual Server has “UDP” set as protocol, and is assigned with a SIP profile.Bash Shellshock Mitigation Using ASM Signatures
Update: The signature mentioned in this article have been released as part of an Attack Signature Update. You may head to https://downloads.f5.com to download the file manually, or use the automatic update feature in ASM. This week we've seen new vulnerabilities with massive damage potential come to light – CVE-2014-6271,CVE-2014-6277 and CVE-2014-7169 - named quite appropriately "Shellshock". Background You can find details regarding this bash vulnerability on the Red Hat security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ In a typical exploit, the payload is sent through a header (typically Cookie, Referrer or User-Agent) and takes advantage of the way the web server saves the data in that request to environment variables. A malicious request will attempt to fool the bash parser by sending a payload that will invoke a system command, for instance: GET /home.php HTTP/1.1 Host: example.com User-Agent: () { :;}; /bin/bash -c "ls" The string "() { :;};" means it is a function declaration. The string is followed by various shell commands – in our case it is execution of the "ls" command. Mitigation using F5 ASM Attack Signatures The following signature will catch attempts to exploit this CVE: headercontent:"() {"; This signature is compatible with all BIG-IP versions. To prevent any other potential exploitation attempts via the URL or a parameter, two additional signatures can be used: uricontent:"() {"; objonly; valuecontent:"() {"; norm; Note: The signatures have been updated to catch exploit attempts in all their variations. It is important to note, that all attempts to exploit this vulnerability via HTTP parameters and several known exploits via the HTTP header are already mitigated using existing "command execution" and "predictable resource location" signatures. Exploits via the Cookie header will encounter the "Cookie not RFC-compliant" violation. You need to make sure they are enabled and are not in staging. To protect your application, create those user-defined signatures and associate them with the relevant security policy. Make sure that the signatures are not in staging.iRule to assist with CVE-2022-22965 mitigation
Hi there, On March 30, 2022, a remote code execution (RCE) vulnerabilitywas found in the Java Spring Framework, identified by the CVE 2022-22965. I am sharing an example iRule to assist with mitigation of this CVE. This may require further customization but it's a great start 🙂 This iRule is not supported by F5. Link to the iRule.The DevCentral Chronicles June Edition 1(6)
Heading into the summer months is always a nice time of year – school is out, warmer weather, BBQs, beaches, baseball and maybe some vacation time. And hopefully all the Dads had a nice Father’s Day as we dive into our 6 th installment of the DC Chronicles. The Chronicles are intended to keep you updated on DevCentral happenings and highlight some of the cool content you may have missed since the last issue and you can always catch up with the links at the bottom. Welcome! We had 20 new articles published since Volume 1, Issue 5, including 5 new Lightboard Lessons! We really enjoy making these and you, the audience, certainly express your enjoyment in watching. John Wagnon lit some cool security related topics like, Explaining TLS 1.3, What Are AEAD Ciphers? and The TLS 1.3 Handshake while Jason Rahm drew up the F5 software lifecycle and BIG-IP Cloud Edition Overview. Since we’re on Cloud, Chris Zhang also wrote up how to Achieve firewall high-availability in Azure with F5. We also published a bunch of materials about our new BIG-IP Cloud Edition. BIG-IP Cloud Edition is designed to enable easy to use and fast self-serve deployments of application services in private and public clouds and is composed of BIG-IP Per-App VEs and BIG-IQ CM 6.0. To get the scoop, you can check out the BIG-IP Cloud Edition FAQ, Building Applications For The Rest Of Us With BIG-IQ 6 and Skies Never Looked So Good With BIG-IP Cloud Edition. DevCentral’s Chase Abbott lays out the details. Moving from Cloud to Security, several vulnerability mitigations from our SIRT team dropped recently. You got coverage for Remote Code Execution with Spring OAuth Extension (CVE-2018-1260), a New BIG-IP ASM v13 Drupal v8 Ready Template, and a New BIG-IP ASM v13 WordPress v4.9 Ready Template. Also filed under Security, Steve Lyons showed how to Configure Smart Card Authentication to BIG-IP Management Interface. Other highlights include Lori MacVittie’s Three HTTP Routing Patterns You Should Know with Eric Chen’s follow on, SNI Routing with BIG-IP. Chen also gives us Clone Pool Across L3 explaining how you can use the “clone pool” feature to copy traffic to an IDS and/or network monitoring device. Jason continues his Getting started with the Python SDK series covering Working with Statistics and Working with Request Parameters and finally, Jie Gao was DevCentral's Featured Member for June. As always, You can stay engaged with @DevCentral by following us on Twitter, joining our LinkedIn Group or subscribing to our YouTube Channel. Look forward to hearing about your BIG-IP adventures. The Chronicles: Volume 1, Issue 1 Volume 1, Issue 2 Volume 1, Issue 3 Volume 1, Issue 4 Volume 1, Issue 5Mitigate L7 DDoS with BIG-IP ASM
Today, let’s look at a couple ways to mitigate an applicationDDoS attack with BIG-IP ASM. We’ve logged into a BIG-IP ASM and navigated to Security>DDoS Protection>DDoS Profiles. In the General Settings of Application Security, we’ll activate an application DoS iRule event. We’ll click TPS-based Detection to see the temporarily lowered TPS thresholds to easily simulate an attack. Often, there are multiple mitigation methods that are sequentially applied as you can see with the Source IP settings. We can also record traffic packet captures during attacks for post analysis. When the user requests a web application proxied by BIG-IP ASM, ASM will create a unique identifier or a Device ID. ASM will inject JavaScript to register each client device. You can see X-Device-ID: at the bottom. And JavaScript incapable clients never make it through. Now that the unit is ready, let’s enable some packet capture and take a go at that damn vulnerable web application. Path for the log files is /var/log/ or /shared/log/…the PCAP folder is empty so let’s see the action. Attack commence in 3-2-1. Some quick refreshes should do as our thresholds are low. The first mitigation is Client Side Integrity Defense. The system issues a client-side integrity challenge that consumes client computation resources and slows down the attack. Next is Built-in Captcha. The third mitigation is Rate Limiting… ..then if they’re still not listening, you can instantly transform into a Honeypot. The logs below show the IP address and the type of mitigation technique deployed. First Integrity, then Captcha, then Rate Limiting, then Honeypot if they don't stop. The traffic you recorded will be found in the, now populated, PCAP folders. Thanks to F5 SE Artiom Lichtenstein for the demo video. ps Related: Lightboard Lessons: What is DDoS? ASM_DosL7 iRule CodeICSA Certified Network Firewall for Data Centers
The BIG-IP platform is now ICSA Certified as a Network Firewall. Internet threats are widely varied and multi-layered. Although applications and their data are attackers’ primary targets, many attackers gain entry at the network layer. Internet data centers and public-facing web properties are constant targets for large-scale attacks by hacker/hactivist communities and others looking to grab intellectual property or cause a service outage. Organizations must prepare for the normal influx of users, but they also must defend their infrastructure from the daily barrage of malicious users. Security administrators who manage large web properties are struggling with security because traditional firewalls are not meeting their fundamental performance needs. Dynamic and layered attacks that necessitate multiple-box solutions, add to IT distress. Traditional firewalls can be overwhelmed by their limited ability to scale under a DDoS attack while keeping peak connection performance for valid users, which renders not only the firewalls themselves unresponsive, but the web sites they are supposed to protect. Additionally, traditional firewalls’ limited capacity to interpret context means they may be unable to make an intelligent decision about how to deliver the application while also keeping services available for valid requests during a DDoS attack. Traditional firewalls also lack specialized capabilities like SSL offload, which not only helps reduce the load on the web servers, but enables inspection, re-encryption, and certificate storage. Most traditional firewalls lack the agility to react quickly to changes and emerging threats, and many have only limited ability to provide new services such as IP geolocation, traffic redirection, traffic manipulation, content scrubbing, and connection limiting. An organization’s inability to respond to these threats dynamically, and to minimize the exposure window, means the risk to the overall business is massive. There are several point solutions in the market that concentrate on specific problem areas; but this creates security silos that only make management and maintenance more costly, more cumbersome, and less effective. The BIG-IP platform provides a unified view of layer 3 through 7 for both general and ICSA required reporting and alerts, as well as integration with SIEM vendors. BIG-IP Local Traffic Manager offers native, high-performance firewall services to protect the entire infrastructure. BIG-IP LTM is a purpose-built, high-performance Application Delivery Controller designed to protect Internet data centers. In many instances, BIG-IP LTM can replace an existing firewall while also offering scale, performance, and persistence. Performance: BIG-IP LTM manages up to 48 million concurrent connections and 72 Gbps of throughput with various timeout behaviors, buffer sizes, and more when under attack. Protocol security: The BIG-IP system natively decodes IPv4, IPv6, TCP, HTTP, SIP, DNS, SMTP, FTP, Diameter, and RADIUS. Organizations can control almost every element of the protocols they’re deploying. DDoS prevention capabilities: An integrated architecture enables organizations to combine traditional firewall layers 3 and 4 with application layers 5 through 7. DDoS mitigations: The BIG-IP system protects UDP, TCP, SIP, DNS, HTTP, SSL, and other network attack targets while delivering uninterrupted service for legitimate connections. SSL termination: Offload computationally intensive SSL to the BIG-IP system and gain visibility into potentially harmful encrypted payloads. Dynamic threat mitigation: iRules provide a flexible way to enforce protocol functions on both standard and emerging or custom protocols. With iRules, organizations can create a zero day dynamic security context to react to vulnerabilities for which an associated patch has not yet been released. Resource cloaking and content security: Prevent leaks of error codes and sensitive content. F5 BIG-IP LTM has numerous security features so Internet data centers can deliver applications while protecting the infrastructure that supports their clients and, BIG-IP is now ICSA Certified as a Network Firewall. ps Resources: F5’s Certified Firewall Protects Against Large-Scale Cyber Attacks on Public-Facing Websites F5 BIG-IP Data Center Firewall – Overview BIG-IP Data Center Firewall Solution – SlideShare Presentation High Performance Firewall for Data Centers – Solution Profile The New Data Center Firewall Paradigm – White Paper Vulnerability Assessment with Application Security – White Paper Challenging the Firewall Data Center Dogma Technorati Tags: F5, big-ip, virtualization, cloud computing, Pete Silva, security, icsa, iApp, compliance, network firewall, internet, TMOS, big-ip, vCMPF5 BIG-IP Platform Security
When creating any security-enabled network device, development teams must fully investigate security of the device itself to ensure it cannot be compromised. A gate provides no security to a house if the gap between the bars is large enough to drive a truck through. Many highly effective exploits have breached the very software and hardware that are designed to protect against them. If an attacker can breach the guards, then they don’t need to worry about being stealthy, meaning if one can compromise the box, then they probably can compromise the code. F5 BIG-IP Application Delivery Controllers are positioned at strategic points of control to manage an organization’s critical information flow. In the BIG-IP product family and the TMOS operating system, F5 has built and maintained a secure and robust application delivery platform, and has implemented many different checks and counter-checks to ensure a totally secure network environment. Application delivery security includes providing protection to the customer’s Application Delivery Network (ADN), and mandatory and routine checks against the stack source code to provide internal security—and it starts with a secure Application Delivery Controller. The BIG-IP system and TMOS are designed so that the hardware and software work together to provide the highest level of security. While there are many factors in a truly secure system, two of the most important are design and coding. Sound security starts early in the product development process. Before writing a single line of code, F5 Product Development goes through a process called threat modeling. Engineers evaluate each new feature to determine what vulnerabilities it might create or introduce to the system. F5’s rule of thumb is a vulnerability that takes one hour to fix at the design phase, will take ten hours to fix in the coding phase and one thousand hours to fix after the product is shipped—so it’s critical to catch vulnerabilities during the design phase. The sum of all these vulnerabilities is called the threat surface, which F5 strives to minimize. F5, like many companies that develop software, has invested heavily in training internal development staff on writing secure code. Security testing is time-consuming and a huge undertaking; but it’s a critical part of meeting F5’s stringent standards and its commitment to customers. By no means an exhaustive list but the BIG-IP system has a number of features that provide heightened and hardened security: Appliance mode, iApp Templates, FIPS and Secure Vault Appliance Mode Beginning with version 10.2.1-HF3, the BIG-IP system can run in Appliance mode. Appliance mode is designed to meet the needs of customers in industries with especially sensitive data, such as healthcare and financial services, by limiting BIG-IP system administrative access to match that of a typical network appliance rather than a multi-user UNIX device. The optional Appliance mode “hardens” BIG-IP devices by removing advanced shell (Bash) and root-level access. Administrative access is available through the TMSH (TMOS Shell) command-line interface and GUI. When Appliance mode is licensed, any user that previously had access to the Bash shell will now only have access to the TMSH. The root account home directory (/root) file permissions have been tightened for numerous files and directories. By default, new files are now only user readable and writeable and all directories are better secured. iApp Templates Introduced in BIG-IP v11, F5 iApps is a powerful new set of features in the BIG-IP system. It provides a new way to architect application delivery in the data center, and it includes a holistic, application-centric view of how applications are managed and delivered inside, outside, and beyond the data center. iApps provide a framework that application, security, network, systems, and operations personnel can use to unify, simplify, and control the entire ADN with a contextual view and advanced statistics about the application services that support business. iApps are designed to abstract the many individual components required to deliver an application by grouping these resources together in templates associated with applications; this alleviates the need for administrators to manage discrete components on the network. F5’s new NIST 800-53 iApp Template helps organizations become NIST-compliant. F5 has distilled the 240-plus pages of guidance from NIST into a template with the relevant BIG-IP configuration settings—saving organizations hours of management time and resources. Federal Information Processing Standards (FIPS) Developed by the National Institute of Standards and Technology (NIST), Federal Information Processing Standards are used by United States government agencies and government contractors in non-military computer systems. FIPS 140 series are U.S. government computer security standards that define requirements for cryptography modules, including both hardware and software components, for use by departments and agencies of the United States federal government. The requirements cover not only the cryptographic modules themselves but also their documentation. As of December 2006, the current version of the standard is FIPS 140-2. A hardware security module (HSM) is a secure physical device designed to generate, store, and protect digital, high-value cryptographic keys. It is a secure crypto-processor that often comes in the form of a plug-in card (or other hardware) with tamper protection built in. HSMs also provide the infrastructure for finance, government, healthcare, and others to conform to industry-specific regulatory standards. FIPS 140 enforces stronger cryptographic algorithms, provides good physical security, and requires power-on self tests to ensure a device is still in compliance before operating. FIPS 140-2 evaluation is required to sell products implementing cryptography to the federal government, and the financial industry is increasingly specifying FIPS 140-2 as a procurement requirement. The BIG-IP system includes a FIPS cryptographic/SSL accelerator—an HSM option specifically designed for processing SSL traffic in environments that require FIPS 140-1 Level 2–compliant solutions. Many BIG-IP devices are FIPS 140-2 Level 2–compliant. This security rating indicates that once sensitive data is imported into the HSM, it incorporates cryptographic techniques to ensure the data is not extractable in a plain-text format. It provides tamper-evident coatings or seals to deter physical tampering. The BIG-IP system includes the option to install a FIPS HSM (BIG-IP 6900, 8900, 11000, and 11050 devices). BIG-IP devices can be customized to include an integrated FIPS 140-2 Level 2–certified SSL accelerator. Other solutions require a separate system or a FIPS-certified card for each web server; but the BIG-IP system’s unique key management framework enables a highly scalable secure infrastructure that can handle higher traffic levels and to which organizations can easily add new services. Additionally the FIPS cryptographic/SSL accelerator uses smart cards to authenticate administrators, grant access rights, and share administrative responsibilities to provide a flexible and secure means for enforcing key management security. Secure Vault It is generally a good idea to protect SSL private keys with passphrases. With a passphrase, private key files are stored encrypted on non-volatile storage. If an attacker obtains an encrypted private key file, it will be useless without the passphrase. In PKI (public key infrastructure), the public key enables a client to validate the integrity of something signed with the private key, and the hashing enables the client to validate that the content was not tampered with. Since the private key of the public/private key pair could be used to impersonate a valid signer, it is critical to keep those keys secure. Secure Vault, a super-secure SSL-encrypted storage system introduced in BIG-IP version 9.4.5, allows passphrases to be stored in an encrypted form on the file system. In BIG-IP version 11, companies now have the option of securing their cryptographic keys in hardware, such as a FIPS card, rather than encrypted on the BIG-IP hard drive. Secure Vault can also encrypt certificate passwords for enhanced certificate and key protection in environments where FIPS 140-2 hardware support is not required, but additional physical and role-based protection is preferred. In the absence of hardware support like FIPS/SEEPROM (Serial (PC) Electrically Erasable Programmable Read-Only Memory), Secure Vault will be implemented in software. Even if an attacker removed the hard disk from the system and painstakingly searched it, it would be nearly impossible to recover the contents due to Secure Vault AES encryption. Each BIG-IP device comes with a unit key and a master key. Upon first boot, the BIG-IP system automatically creates a master key for the purpose of encrypting, and therefore protecting, key passphrases. The master key encrypts SSL private keys, decrypts SSL key files, and synchronizes certificates between BIG-IP devices. Further increasing security, the master key is also encrypted by the unit key, which is an AES 256 symmetric key. When stored on the system, the master key is always encrypted with a hardware key, and never in the form of plain text. Master keys follow the configuration in an HA (high-availability) configuration so all units would share the same master key but still have their own unit key. The master key gets synchronized using the secure channel established by the CMI Infrastructure as of BIG-IP v11. The master key encrypted passphrases cannot be used on systems other than the units for which the master key was generated. Secure Vault support has also been extended for vCMP guests. vCMP (Virtual Clustered Multiprocessing) enables multiple instances of BIG-IP software to run on one device. Each guest gets their own unit key and master key. The guest unit key is generated and stored at the host, thus enforcing the hardware support, and it’s protected by the host master key, which is in turn protected by the host unit key in hardware. Finally F5 provides Application Delivery Network security to protect the most valuable application assets. To provide organizations with reliable and secure access to corporate applications, F5 must carry the secure application paradigm all the way down to the core elements of the BIG-IP system. It’s not enough to provide security to application transport; the transporting appliance must also provide a secure environment. F5 ensures BIG-IP device security through various features and a rigorous development process. It is a comprehensive process designed to keep customers’ applications and data secure. The BIG-IP system can be run in Appliance mode to lock down configuration within the code itself, limiting access to certain shell functions; Secure Vault secures precious keys from tampering; and optional FIPS cards ensure organizations can meet or exceed particular security requirements. An ADN is only as secure as its weakest link. F5 ensures that BIG-IP Application Delivery Controllers use an extremely secure link in the ADN chain. ps Resources: F5 Security Solutions Security is our Job (Video) F5 BIG-IP Platform Security (Whitepaper) Security, not HSMs, in Droves Sometimes It Is About the Hardware Investing in security versus facing the consequences | Bloor Research White Paper Securing Your Enterprise Applications with the BIG-IP (Whitepaper) TMOS Secure Development and Implementation (Whitepaper) BIG-IP Hardware Updates – SlideShare Presentation Audio White Paper - Application Delivery Hardware A Critical Component F5 Introduces High-Performance Platforms to Help Organizations Optimize Application Delivery and Reduce Costs Technorati Tags: F5, PCI DSS, virtualization, cloud computing, Pete Silva, security, coding, iApp, compliance, FIPS, internet, TMOS, big-ip, vCMPF5 Friday: Mitigating the THC SSL DoS Threat
The THC #SSL #DoS tool exploits the rapid resource consumption nature of the handshake required to establish a secure session using SSL. A new attack tool was announced this week and continues to follow in the footsteps of resource exhaustion as a means to achieve a DoS against target sites. Recent trends in attacks show an increasing interest in maximizing effect while minimizing effort. This means a move away from traditional denial of service attacks that focus on overwhelming sites with traffic and toward attacks that focus on rapidly consuming resources, instead. Both have the same ultimate goal: overwhelming infrastructure, whether server or router or insert infrastructure component of choice>. The latest SSL-based attack falls into the modern category of denial of service attacks in that it’s not an attempt to overwhelm with traffic, but rather to consume resources on servers such that capacity and the ability to respond to legitimate requests is eliminated. The blog post announcing the exploit tools explains: Establishing a secure SSL connection requires 15x more processing power on the server than on the client. THC-SSL-DOS exploits this asymmetric property by overloading the server and knocking it off the Internet. This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection. -- THC SSL DOS Tool Released As the blog points out, there is no resolution to this exploit. Common mitigation techniques include the use of an SSL accelerator, i.e. a reverse-proxy capable device with specialized hardware designed to improve the processing capability of SSL and associated cryptographic functions. Modern application delivery controllers like BIG-IP include such hardware by default and make use of its performance and capacity-enhancing abilities to offset the operational costs of supporting SSL-secured communication. BIG-IP MITIGATION There are actually several ways in which BIG-IP can mitigate the potential impact of this kind of attack. First and foremost is simply its higher capacity for connections and processing of SSL / RSA operations. BIG-IP can manage myriad more connections – secure or not – than a typical web server and thus it may be, depending on the hardware platform on which BIG-IP is deployed, that the mitigation rests merely on having a BIG-IP in the path of the attack. In the case that it is not, or if organizations desire a more proactive approach to mitigation, there are two additional options: 1. SSL renegotiation, which is in part the basis for the attack (it’s what allows a relatively few clients to force the server to consume more and more resources), can be disabled in BIG-IP v11 and v10.2.3. This may break some applications and/or clients so this option may want to be left as a “last resort” or the risks carefully weighed before deploying such a configuration. 2. An iRule that drops connections over which a client attempts to renegotiate more than five times in a given 60-second interval can be deployed. As noted by David Holmes and the iRule author, Jason Rahm, “By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack. There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.” The full details and code for the iRule can be found in the DevCentral article “SSL Renegotiation DOS attack – an iRule Countermeasure” UPDATE 11/1/2011: David Holmes has included an optimized version of the iRule in his latest blog, "The SSL Renegotation Attack is Back." His version uses the normal flow key (instead of a random key), adds a log message, and optimizes memory consumption. Regardless of the mitigating technique used, BIG-IP can provide the operational security necessary to prevent such consumption-leeching attacks from negatively impacting applications by defeating the attack before it reaches application infrastructure. Stay safe!Security’s FUD Factor
Had a short but interesting twitter exchange with @securityincite@Gillis57and @essobi(Mike Rothman, Gillis Jones andnot sure (sorry!!)respectively) about usingFear,Uncertainty andDoubt when talking IT security services. @Gillis57initially asked, ‘Question: We discuss FUD constantly (and I agree that it's too prominent) But isn't security inherently built upon fear?’ I sent an‘09 Rothman article(@securityincitesaid it was ‘old school’ but still has some great comments) about that very topic. Soon, @essobichimed in with, ‘Our foundation shouldn't be fear, it should be education. :D,’ @Gillis57responded, ‘So, look. I agree wholeheartedly, but why do people need to be educated?’ @essobianswered, ‘imo? Bad programming/exploitable logic processes. we need to raise the bar or lower expectations.’ @Gillis57added, ‘I really don't think we need to keep selling fear, but denying that we are a fear based industry isn't helping.’ @securityincitewizdom’d with, ‘Fear is a tactic like anything else. Depends in situation, context, catalyst. And use sparingly.’And Iconceded that, ‘splitting hairs but I try to talk about risk rather than fear - what's the risk if...which often generates fear.’ Most of the time when we talk about security there is a fear factor because we are talking about risk. Risk is the potential for something Bad happening and typically those things scare or make us uncomfortable. Often when vendors talk about things like protection, benefits, etc, it’s measured in terms of numbers, stats, performance…metrics. Security is also about Peace of Mind; a feeling that you have. Those military people who can get some good sleep even with bullets flying over their heads have peace of mind. Even in a very high risk, dangerous, vulnerable and insecure environment, they feel secure. I saw an article about the difference betweenselling insurance and the lottery – Fear vs. Dreams. Maybe we should discuss IT Security in terms of how it has made an IT guy’s life better? I think it would be cool if ‘security’ case studies included a side bar or something with a quote that brags, ‘Now that we have this solution installed, I’m able to attend my daughter’s piano recitals.’ ‘I’m able to get a good night’s sleep knowing that our web site is ok/won’t get paged at 3AM/won’t have to work for 16hrs.’ Adding to the quality of life over and above the usual ROI/TCO/performance/$$. How it may have enhanced life. How it gave peace of mind. How it Reduced Stress. How it allowed someone to be home for dinner. How it allowed someone to enjoy the weekend, do that Science Fair thing with the kid, take a longer vacation… It might be cool for the industry (and the general public) to read how another’s life improved when security is deployed along with all the breaches and headaches. Ultimately, that’s what we are all chasing as humans anyway – that harmony, balance, peace of mind, quality of life, family, love…the cores of our being rather than what we do for a job – even though our work does have a lot to do with quality of life. I also think that education is part of our duty. Not in the ‘Knights of the Roundtable’ duty but if someone needs our security expertise and is willing to learn, sharing (and ultimately, awareness) is important to ensure a more informed public. That is simply being a good internet citizen. And yes, fear does have it’s place especially when someone is not getting it or ignoring that others are at risk. We frequently talk in terms of rational thinking ($$/performance) when security is quite often about an emotional feeling. That’s why some often use FUD to sell security:Fear: emotional,Uncertainly: more emotional than rational,Doubt: gut feeling with little data. But instead of tapping those negative emotions, we should shoot for the Feel Good emotions that provide safety and security. The Dream. -eh, just an idea. And many Mahalos to @securityincite@Gillis57and @essobifor a blog idea. ps References Abandon FUD, Scare Tactics and Marketing Hype Are you Selling Fear or Dreams? Death to FUD Selling FUD creeping back into security sell Time To Deploy The FUD Weapon? How To Sell Security Solutions Without Using Fear, Uncertainty And Doubt Researchers Warn Against Selling On Security Hype How to Sell Security, Externality and FUD How to Sell Security The Four Horsemen of the Cyber-Apocalypse: Security Software FUD(awesome article) Technorati Tags:F5,smartphone,insiders,byod,PeteSilva,security,business,education,technology,fud,threat,human behavior,kiosk,malware,fear,web,internet,twitterYou’ll Shoot Your Eye Out…
…is probably one of the most memorable lines of any Holiday Classic. Of course I’m referring to A Christmas Story, where a young Ralphie tries to convince his parents, teachers and Santa that the Red Ryder BB Gun is the perfect present. I don’t know of there was a warning label on the 1940’s edition box but it is a good reminder from a security perspective that often we, meaning humans, are our own worst enemy when it comes to protecting ourselves. Every year about 100 or so homes burn down due to fried turkeys. A frozen one with ice crystals straight in or the ever famous too much oil that overflows and toasts everything it touches. Even with the warnings and precautions, humans still take the risk. Warning: You can get burned badly. As if the RSA breach wasn’t warning enough about the perils of falling for a phishing scam, we now learn that the South Carolina Department of Revenue breach was also due to an employee, and it only takes one, clicking a malicious email link. That curiosity lead to over 3.8 million Social Security numbers, 3.3 million bank accounts, thousands of credit cards along with 1.9 million dependant’s information being exposed. While the single click started it all, 2-factor authentication was not required and the stored info was not encrypted, so there is a lot of human error to go around. Plus a lot of blame being tossed back and forth – another well used human trait – deflection. Warning: Someone else may not protect your information. While working the SharePoint Conference 2012 in Vegas a couple weeks ago, I came across a interesting kiosk where it allows you to take a picture and post online for free to any number of social media sites. It says ‘Post a picture online for free.’ but there didn’t seem to be a Warning: ‘You are also about to potentially share your sensitive social media credentials or email, which might also be tied to your bank account, into this freestanding machine that you know nothing about.’ I’m sure if that was printed somewhere, betters would think twice about that risk. If you prefer not to enter social media info, you can always have the image emailed to you (to then share) but that also (obviously) requires you to enter that information. While logon info might not be stored, email is. Yet another reason to get a throw away email address. I’m always amazed at all the ways various companies try to make it so easy for us to offer up our information…and many of us do without considering the risks. In 2010, there were a number of photo kiosks that were spreading malware. Warning: They are computers after all and connected to the internet. Insider threats are also getting a lot of attention these days with some statistics indicating that 33% of malicious or criminal attacks are from insiders. In August, an insider at Saudi Aramco released a virus that infected about 75% of the employee desktops. It is considered one of the most destructive computer sabotages inflicted upon a private company. And within the last 2 days, we’ve learned that the White House issued an Executive Order to all government agencies informing them of new standards and best practices around gathering, analyzing and responding to insider threats. This could be actual malicious, disgruntled employees, those influenced by a get rich quick scheme from an outsider or just ‘compromised’ employees, like getting a USB from a friend and inserting it into your work computer. It could even be simple misuse by accident. In any event, intellectual property or personally identifiable information is typically the target. Warning: Not everyone is a saint. The Holidays are still Happy but wear your safety glasses, don’t click questionable links even from friends, don’t enter your logon credentials into a stray kiosk and a third of your staff is a potential threat. And if you are in NYC for the holidays, a limited run of "Ralphie to the Rescue!" A Christmas Story, The Musical is playing at the Lunt-Fontanne Theatre until Dec 30th. ps References How One Turkey Fryer Turned Into A 40-foot Inferno That Destroyed Two Cars And A Barn S.C. tax breach began when employee fell for spear phish 5 Stages of a Data Breach Thinking about Security from the Inside Out Obama issues insider threat guidance for gov't agencies National Insider Threat Policy and Minimum Standards for Executive Branch Insider Threat Programs Insiders Big Threat to Intellectual Property, Says Verizon DBIR Negligent Insiders and Malicious Attacks Continue to Pose Security Threat Infographic: Protect Yourself Against Cybercrime The Exec-Disconnect on IT Security "Ralphie to the Rescue!" A Christmas Story, The Musical Opens On Broadway Nov. 19
