Research

So why are we looking at big data, and what problems can we expect it to solve that we couldn’t before? Most SIEM platforms struggle to keep up with emerging needs for two reasons. The first is that threat data does not come neatly packaged from traditional sources, such as syslog and netflow events. There are many different types of data, data feeds, documents, and communications protocols that contain diverse clues to a data breaches or ongoing attacks. We see clear demand to analyze a broader data set in order hopes of detecting advanced attacks. The second issue is that many types of analysis, correlation, and enrichment are computationally demanding. Much like traditional multi-dimensional data analysis platforms, crunching the data takes horsepower. More data is being generated; add more types of data we want, and multiply that by additional analysess – and you get a giant gap between what you need to do and what you can presently do. Our last post considered what big data is and how NoSQL database architectures inherently address several of the SIEM pain points. In fact, the 3Vs (Volume, Velocity, & Variety) of big data coincide closely with three of the main problems faced by SIEM systems today: scalability, performance, and effectiveness. This is why big data is such an important advancement for SIEM. Volume and velocity problems are addressed by clustering systems to divide load across many commodity servers, and variability through the inherent flexibility of big data / NoSQL. But of course there is more to it. Analysis: Looking at More Two of the most serious problems with current SIEM solutions are that they struggle with the amount of data to be managed, and they cannot deal with the “data velocity” of near-real-time events. Additionally, they need to accept and parse new and diverse data types to support new types of analysis. There are many different types of event data, any of which might contain clues to security threats. Common data types include: Human-readable data: There is a great deal of data which humans can process easily, but which is much more difficult for machines – including blog comments and Twitter feeds. Tweets, discussion fora, Facebook posts, and other types of social media are all valuable for threat intelligence. Some attacks are coordinated in fora, which means companies want to monitor these fora for warnings of possible or imminent attacks, and perhaps even details of the attacks. Some botnet command and control (C&C) communications occur through social media, so there is potential to detect infected machines through this traffic. Telemetry feeds: Cell phone geolocation, lists of sites serving malware, mobile device IDs, HR feeds of employee status, and dozens of other real-time data feeds denote changes in status, behavior, and risk profiles. Some of these feeds are analyzed as the stream of events is captured, while others are collected and analyzed for new behaviors. There are many different use cases but security practitioners, observing how effectively retail organizations are able to predict customer buying behavior, are seeking the same insight into threats. Financial data: We were surprised to learn how many customers use financial data purchased from third parties to help detect fraud. The use cases we heard centered around SIEM for external attacks against web services, but they were also analyzing financial and buying history to predict misuse and account compromise. Contextual data: This is anything that makes other data more meaningful. Contextual data might indicate automated processes rather than human behavior – a too-fast series of web requests, for example, might indicate a bot rather than a human customer. Contextual data also includes risk scores generated by arbitrary analysis of metadata, and detection of odd or inappropriate series of actions. Some is simply collected from a raw event source while other data is derived through analysis. As we improve our understanding of where to look for attack and breach cluse, we will leverage new sources of data and examine them in new ways. SIEM generates some contextual data today, but collection of a broader variety of data enables better analysis and enrichment. Identity and Personas: Today many SIEMs link with directory services to identify users. The goal is to link a human user to their account name. With cloud services, mobile devices, distributed identity stores, identity certificates, and two-factor identity schemes, it has become much harder to link human beings to account activity. As authentication and authorization facilities become more complex, SIEM must connect to and analyze more and different identity stores and logs. Network Data: Some of you are saying “What? I thought all SIEMs looked at network flow data!” Actually, some do but others don’t. Some collect and alert on specific known threats, but only a tiny portion of that passes down the wire. Cheap storage makes it feasible to store more network events and perform behavioral computation on general network trends, service usage, and other pre-computed aggregate views of network traffic. In the future we may be able to include all data. Each of these examples demonstrates what will be possible in the short term. In the long term we may record any and all useful or interesting data. If we can link in data sets that provide a different views or help us make better decisions, we will. We already collect many of these data types, but we have been missing the infrastructure to analyze them meaningfully. Analysis: Doing It Better One limitation of many SIEM platforms is their dependence on relational databases. Even if you strip away relational constructs that limit insertion performance, they still rely on a SQL language with traditional language processors. The fundamental relational database architecture was designed and optimized for relational queries. Flexibility is severely limited by SQL – statements always include FROM and WHERE clauses, and we have a limited number of comparison operators for searching. At a high level we may have Java support, but the actual queries still devolve down to SQL statements. SQL may be a trusty

So why are we talking about this? Because APIs are becoming the de facto service interface – not only for cloud and mobile, but for just about every type of service. The need for security around these APIs is growing, which is why we have seen a rush of acquisitions to fill security product gaps. In what felt like a couple weeks Axway acquired Vordel, CA acquired Layer7, and Intel acquired Mashery. The acquirers all stated these steps were to accommodate security requirements stemming from steady adoption of APIs and associated web services. Our goal for this paper is to help you understand the challenges of securing APIs and to evaluate technology alternatives so you can make informed decisions about current trends in the market. We will start our discussion by mentioning what’s at stake, which should show why certain features are necessary. API gateways have a grand and audacious goal: enablement. Getting developers the tools, data, and functionality they need to realize the mobile, social, cloud and other use cases the enterprise wants to deliver. There is a tremendous amount of innovation in these spaces today, and the business goal is get to market ASAP. At the same time, security is not a nice-to-have – it’s a hard requirement. After all, the value of mobile, social, and cloud applications is in mixing enterprise functionality inside and outside the enterprise. And riding along is an interesting mix of user personas: customers, employees, and corporate identities, all mingling together in the same pool. API gateways must implement real security policies and protocols to protect enterprise services, brands, and identity. This research paper will examine current requirements and technical trends in API security. API gateways are not sexy. They do not generate headlines like cloud, mobile, and big data. But the APIs are the convergence point for all these trends, and the crux of IT innovation today. We all know cloud services scale almost too well to be real, at a price that seems to good to be true. But the APIs are part of what makes them so scalable and cheap. Of course open, API-driven, multi-tenant environments bring new risks along with their new potentials. As Netflix security architect Jason Chan says, securing your app on Amazon Cloud is like rock climbing – Amazon gives you a rope and belays you, but you are on the rock face. You are the one at risk. How do you manage that risk? API gateways play a central role in limiting the cloud’s attack surface and centralizing policy enforcement. Mobile apps pose similar risks in an entirely different technical environment. There is endless amount hype about iOS and Android security. But where are the breaches? On the server side. Why? Because attackers are pragmatic, and that’s where the data is. Mobile apps have vulnerabilities that attackers can go after one by one, but a breach of the server-side APIs exposes the whole enterprise enchilada. Say it with me in your best Taco Bell Chihuahua accent: The whole enchilada! Like cloud applications, API gateways need to reduce the enterprise’s risk by limiting attack surface. And mobile apps use web services differently than other enterprise applications, communications are mostly asynchronous, and the identity tokens are different too – expect to see less SAML or proprietary SSO, and more OAuth and OpenID Connect. API gateways address the challenges raised by these new protocols and interactions. APIs are an enabling technology, linking new and old applications together into a unified service model. But while cloud, mobile, and other innovations drive radical changes in the data center, one thing remains the same: the speed at which business wants to deploy new services. Fast. Faster! Yesterday, if possible. This makes developer enablement supremely important, and is why we need to weave security into the fabric of development – if it is not integrated at a fundamental level, security gets be removed as an impediment to shipping. The royal road is to things that make it easy for developers to understand how to build and deploy an app, grok the interfaces and data, and quickly provision developers and their app users to login – this is how IT shops are organizing teams, projects, and tech stacks. The DMZ has gone the way of the dodo. API gateways are about enabling developers to build cloud, mobile, and social apps on enterprise data, layered over existing IT systems. Third-party cloud services, mobile devices, and work-from-anywhere employees have destroyed (or at least completely circumvented) the corporate IT ‘perimeter’ – the ‘edge’ of the network has so many holes it no longer forms a meaningful boundary. And this trend, fueled by the need to connect in-house and third-party services, is driving the new model. API gateways curate APIs, provision access to users and developers, and facilitate key management. For security this is the place to focus – to centralize policy enforcement, implement enterprise protocols and standards, and manage the attack surface. This paper will explore the following API gateway concepts in detail. The content will be developed and posted to the Securosis blog for vetting by the developer and security community. As always, we welcome your feedback – both positive and negative. Our preliminary outline is: Access Provisioning: We will discuss developer access provisioning, streamlining access to tools and server support, user and administrator provisioning, policy provisioning and management, and audit trails to figure out who did what. Developer Tools: We will discuss how to maintain and manage exposed services, a way to catalogue services, client integration, build processes, and deployment support. Key Management: This post will discuss creating keys, setting up a key management service, key and certificate verification, and finally the key management lifecycle (creation, revocation, rotation/updating). Implementation: Here we get into the meat of this series. We will discuss exposing APIs and parameters, URL whitelisting, proper parameter parsing, and some deployment options that effect security. Buyers Guide: We will wrap this series with a brief buyers guide to help you understand the differences between implementations, as well as key considerations when establishing your evaluation priorities. We will also cover

I haven’t been writing much over the past few weeks because I took a few weeks with the family back in Boulder. The plan was to work in the mornings, do fun mountain stuff in the afternoons with the kids, and catch up with friends in the evenings. But the trip ended up turning into a bit of medical tourism when a couple bugs nailed us on day one. For the record, I can officially state that microbrews do not seem to cure viruses. But the research continues… It was actually great to get back home and catch up as best we could under the circumstances. My work suffered but we managed to hit a major chunk of the to-do list. For the kids I think the highlight was me waking up, noticing it was raining, and bundling the family up to the Continental Divide to chase snow. We bounced along an unpaved trail road in the rain, keeping one eye on the temperature and the other on our altitude, until the wet stuff turned into the white stuff. Remember, we live in Phoenix – when it started dumping right when we hit the trailhead, with enough accumulation for snowmen and angels, I was in Daddy heaven. For me, aside from generally catching up with people (and setting a PR in the Bolder Boulder 10K), another highlight was grabbing lunch with some rescue friends and then hanging out in the new headquarters with the kids for a couple hours. It has been a solid 7-8 years since I was on a call, but back at the Cage, surrounded by the gear I used to rely on and vehicles I used to drive, it all came back. Surprisingly little has changed, and I was really hoping the pager would go off so I might hitch along on a call. Er… then again, I’m not sure you are allowed to respond with lights and sirens when kids are in the back in their car seats. There is an intensity to the rescue community that even the security community doesn’t quite match. Shared sweat and blood in risky conditions, as I wrote about in The Magazine. That doesn’t mean it’s all one big lovefest, and there’s no shortage of personal and professional drama, but the bonds formed are intense and long-lasting. And the toys? Oh, man, you can’t beat the toys. That part of my life is on hold for a while as I focus on kids and the company, but it’s comforting to know that not only is it still there, it is still very familiar too. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on Database DoS. Favorite Securosis Posts David Mortman: New Google disclosure policy is quite good. Adrian Lane: Mobile Security Breaches. Astute, concise analysis from Mogull. Rich: Security Analytics with Big Data: New Events, New Approaches. Adrian is killing it with this series. Other Securosis Posts API Gateways: Security Enabling Innovation [New Series]. Matters Requiring Attention: 100 million or so. Apple Expands Gatekeeper. Incite 6/5/2013: Working in the House. Oracle adopts Trustworthy Computing practices for Java. A CISO needs to be a business person? No kidding… Security Analytics with Big Data: Defining Big Data. LinkedIn Rides the Two-Factor Train. Security Surrender. Finally! Lack of Security = Loss of Business. Network-based Malware Detection 2.0: Scaling NBMD. Friday Summary: May 31, 2013. Evernote Business Edition Doubles up on Authentication. Favorite Outside Posts David Mortman: Data Skepticism. Adrian Lane: NSA Collects Verizon Customer Calls. Interesting read, but not news. We covered this trend in 2008. The question was why the government gave immunity to telecoms for spying on us, and we now know: because they were doing it for the government. Willingly or under duress is the current question. Rich: Why we need to stop cutting down security’s tall poppies. Refreshing perspective. Research Reports and Presentations Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts Democratic Senator Defends Phone Spying, And Says It’s Been Going On For 7 Years. Expert Finds XSS Flaws on Intel, HP, Sony, Fujifilm and Other Websites. Whom the Gods Would Destroy, They First Give Real-time Analytics. Apple Updates OS X, Safari. Original Bitcoin Whitepaper. Unrelenting AWS Growth. Not security related, but the most substantive cloud adoption numbers I have seen. Note that the X axis of that graph is logarithmic – not linear! StillSecure acquired. Microsoft, US feds disrupt Citadel botnet network. Blog Comment of the Week This week’s best comment goes to Andy, in response to LinkedIn Rides the Two-Factor Train. This breaks the LinkedIn App for Windows phone. But who uses Windows phone, besides us neo-Luddites who refuse to buy into the Apple ecosystem? Share:

Once, years ago, I made the mistake of saying the Boss didn’t work. I got that statement shoved deep into my gullet because she works harder than I do. She just works in the house. My job is relatively easy – I can work from anywhere, with clients I enjoy, doing stuff that enjoy doing. Often it doesn’t feel like work at all. Compare that to the Boss, who has primary responsibility for the kids. That involves making sure they: get their homework done, are learning properly, have the support they need, and participate in their activities. But that’s the comparatively easy stuff and it’s not easy at all. She spends a lot more of her time managing the drama, which is ramping up for XX1 significantly as she and friends enter the tween stage. She also take very seriously her role of making sure the kids are well behaved, polite, and productive. And it shows. I’m biased, but my kids rarely do cringe-worthy stuff in public. I do have a minor hand in this stuff but she drives the ship. And why am I writing this now? No, I didn’t say anything stupid again to end up in the dog house. I just see how she’s handling her crunch time, which is getting the kids ready for camp, while making sure they see their friends before they head off for the summer, and working around a trip up North to see my Dad. Compared to crunch time the school year is a walk in the park. For those of you who don’t understand the misery of preparing for sleepaway camp, the camp sends a list of a zillion things you have to get. Clothes, towels, sheets, sporting equipment, creature comforts… the list is endless, and everything needs to have your kid’s name in it – if you want it to come back, anyway. Our situation is complicated because we have to ship the stuff to PA. Not only does she need to get everything, but everything needs to fit into two duffel bags. Over the years the intensity of crunch time has increased significantly. Four years ago she only had to deal with XX1 – that was relatively easy. Then XX1 and XX2 went to camp, but it was still manageable. But last year we had all three kids in camp, and decided to take a trip to Barcelona a month before they were due to leave, and went to Orlando for the girls to dance. It was nuts. This year she is way ahead of the game. We are two weeks out and pretty much everything is bought, labeled, and arranged. It’s really just a matter of packing the bags now. The whole operation ran like a well-oiled machine this year. Bravo! I am the first to criticize when stuff doesn’t work well, and usually the last to give credit when things work efficiently. I have already moved on to the next thing. We don’t have a 360-degree review process and we don’t pay bonuses at the end of the year in Chez Rothman. Working in our house is a thankless job. So it’s time to give credit where it’s due. But more importantly, she can now enjoy the next two weeks before the kids head off – without spending all her time buying, packing, and other stressful stuff. And I should also bank some karma points with the Boss to use the next time I do something stupid. Which should be in 3, 2, 1… –Mike Photo credit: “IT Task List” originally uploaded by Paul Gorbould Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Quick Wins with Website Protection Services Deployment and Ongoing Management Protecting the Website Are Websites Still the Path of Least Resistance? Network-based Malware Detection 2.0 Scaling NBMD Evolving NBMD Advanced Attackers Take No Prisoners Security Analytics with Big Data Use Cases Introduction Newly Published Papers Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Understanding and Selecting a Key Management Solution Building an Early Warning System Implementing and Managing Patch and Configuration Management Incite 4 U Your professionalism offends me… Our man in Ireland, Brian Honan, brings up a third rail of sorts regarding some kind of accreditation for security folks. He rightly points out that there is no snake oil defense. But it’s not clear whether he wants folks to go to charm school or to learn decent customer skills so the bad apples don’t reflect badly on our industry. Really? Shack responds with a resounding no, but more because he’s worried about losing the individuality of the characters who do security. I don’t think we need yet another group to teach folks to wear long sleeves if they have tattoos. Believe me, if folks are worried about getting a professional security person, I’m sure one of the big accounting firms would be happy to charge them $300/hour for a n00b to show up in a suit. And some of the best customers are the ones who have bought snake oil in the past. Presumably they learned something and know what questions to ask. – MR BYOD in the real world: For the most part, the organizations I talk with these days are generally in favor of BYOD, with programs to allow at least some use of personally owned computing devices. Primarily they support mobile phones, but they expanding more quickly than most people predicted to laptops and tablets. Network World has a nice, clear article with some examples of BYOD programs in real, large organizations. These are refreshingly practical, with a focus on basic management and a minimal footprint on the devices. We’re talking ActiveSync and passcode enforcement, not those crazy virtual/work/personal swapping modes some vendors promote. I had another discussion with some enterprise managers about BYOD today and they

From an article based on ‘work’ by Check Point: 79% of businesses had a mobile security incident in the past year, in many cases incurring substantial costs, according to Check Point. The report found mobile security incidents cost over $100,000 for 42% of respondents, including 16% who put the cost at more than $500,000. Bullshit. Share:

I missed this when the update went out last night, but Gregg Keizer at Infoworld caught it: “Starting with OS X 10.8.4, Java Web Start applications downloaded from the Internet need to be signed with a Developer ID certificate,” Apple said. “Gatekeeper will check downloaded Java Web Start applications for a signature and block such applications from launching if they are not properly signed.” This was a known hole – great to see it plugged. Share:

Brian Krebs posted a detailed investigative piece on the 2011 breach of Fidelity National Information Services (FIS) and subsequent ATM thefts. I warn you that it’s long but worth the read. At least if your prescription for anti-depressants is current. Each paragraph seems to include some jaw-dropping fact about FAIL. A couple choice quotes from the article: The company came under heavy scrutiny from banking industry regulators in the first quarter of 2011, when hackers who had broken into its networks used that access to orchestrate a carefully-timed, multi-million dollar ATM heist. In that attack, the hackers raised or eliminated the daily withdrawal limits for 22 debit cards they’d obtained from FIS’s prepaid card network. The fraudsters then cloned the cards and distributed them to co-conspirators who used them to pull $13 million in cash from FIS via ATMs in several major cities across Europe, Russia and Ukraine. $13 mil is a lot of money from an ATM network through only 22 debit cards… … The FDIC found that even though FIS has hired a number of incident response firms and has spent more than $100 million responding to the 2011 breach, the company failed to enact some very basic security mechanisms. For example, the FDIC noted that FIS routinely uses blank or default passwords on numerous production systems and network devices, even though these were some of the same weaknesses that “contributed to the speed and ease with which attackers transgressed and exposed FIS systems during the 2011 network intrusion. … “Enterprise vulnerability scans in November 2012, noted over 10,000 instances of default passwords in use within the FIS environment. So our favorite new acronym du jour is MRA. Matters Requiring Attention. FIS has eight. Eight is a lot or at least that is what the FDIC said. It looks like the top line description of one these MRAs is “roll out a centrally managed scanning methodology to address secure coding vulnerabilities across FIS developed applications”. Hopefully the next MRA reads: “Fix the millions of lines of buggy code and all your crappy development processes. Oh, and some developer training would help”. Problem identification is one thing – fixing them is something else. With so many years in security between us we seldom read about a breach that shocks us, but if these facts are true this is such a case. If there is a proverbial first step in security, it is don’t leave passwords at the default. Hijacking accounts through default passwords is the easiest attack to perform, very difficult to detect, and costs virtually nothing to prevent. It is common for large firms to miss one or two default application passwords, but 10k is a systemic problem. It should be clear that if you don’t have control over your computer systems you don’t have control over your business. And if you don’t get basic security right, your servers serve whomever. The other head-scratching facet of Kreb’s post’s claim that FIS spent one hundred million dollars on breach response. If that’s true, and they still failed to get basic security in place, what exactly were they doing? One could guess they spent this money on consultants to tell them how they screwed up and lawyers to minimize further legal exposure. But if you don’t fix the root problem there is a strong likelihood the attackers will repeat their crime – which seems to be what happened with an unnamed United Arab Emirates bank earlier this year. Personally I would carve out a few thousand dollars for vulnerability scanners, password managers and HR staff to hire all new IT staff who have been trained to use passwords! In an ideal world, we would ask further questions, like who gets notified when thresholds change for something as simple as ATM withdrawal limits? Some understanding of account history would make sense to find patterns of abuse. Fraud detection is not a new business process, but it is hard to trust anything that comes out of a system pre-pwned with default passwords. Share:

It amazes to me that articles like CISOs Must Engage the Board About Information Security and The Demise of the Player/Manager CISO even need to be written. If you sit in the CISO chair and this wasn’t already obvious to you, you need to find another job. Back when I launched the Pragmatic CSO in 2007 I wrote a few tips to help CSOs get their heads on straight. Here is the first one: Tip #1: You are a business person, not a security person When I first meet a CSO, one of the first things I ask is whether they consider themselves a “security professional” or a “finance/healthcare/whatever other vertical” professional. 8 out of 10 times they respond “security professional” without even thinking. I will say that it’s closer to 10 out of 10 with folks that work in larger enterprises. These folks are so specialized they figure a firewall is a firewall is a firewall and they could do it for any company. They are wrong. One of the things preached in the Pragmatic CSO is that security is not about firewalls or any technology for that matter. It’s about protecting the systems (and therefore the information assets) of the business and you can bet there is a difference between how you protect corporate assets in finance and consumer products. In fact there are lots of differences between doing security in most major industries. There are different businesses, they have different problems, they tolerate different levels of pain, and they require different funding models. So Tip #1 is pretty simple to say, very hard to do – especially if you rose up through the technical ranks. Security is not one size fits all and is not generic between different industries. Pragmatic CSO’s view themselves as business people first, security people second. To put it another way, a healthcare CSO said it best to me. When I asked him the question, his response was “I’m a healthcare IT professional that happens to do security.” That was exactly right. He spent years understanding the nuances of protecting private information and how HIPAA applies to what he does. He understood how the claims information between providers and payees is sent electronically. He got the BUSINESS and then was able to build a security strategy to protect the systems that are important to the business. I was in a meeting of CISOs earlier this year, and one topic that came up (inevitably) was managing the board. I told those folks that if they don’t have frequent contact, and a set of allies on the Audit Committee, they are cooked. It’s as simple as that. The full board doesn’t care too much about security, but the audit committee needs to. So build those relationships and make sure you can pick up the phone and tell them what they need to know. Or dust off your resume. You will be needing it in the short term. Share:

Okay, I had to troll a bit with that title. From a piece in SC Magazine: Oracle formally has announced improvements in Java that are expected to harden a software line with a checkered security past. Oracle’s post has the details. Java has been part of Oracle’s Software Assurance processes since it was acquired, but they aren’t as robust as Microsoft’s Trustworthy Computing principles. Not that Oracle is following Microsoft (DO NOT TAUNT HAPPY FUN ORACLE) but there are two specific principles they are moving toward: Secure by design. Instead of code testing and bug fixing, they announced they are moving into stronger sandboxing and fundamental security. Secure by default. Altering existing settings in the product for a more secure initial state. If they keep on this path and build a stronger sandbox, Java in the browser might make a return just in time for HTML5 to kill it. But hey, at least then it won’t be because of security. Share:

Google has stated they will now disclose vulnerability details in 7 days under certain circumstances: Based on our experience, however, we believe that more urgent action – within 7 days – is appropriate for critical vulnerabilities under active exploitation. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised. Gunter Ollm, among others, doesn’t like this: The presence of 0-day vulnerability exploitation is often a real and considerable threat to the Internet – particularly when very popular consumer-level software is the target. I think the stance of Chris Evans and Drew Hintz over at Google on a 60-day turnaround of vulnerability fixes from discovery, and a 7-day turnaround of fixes for actively exploited unpatched vulnerabilities, is rather naive and devoid of commercial reality. As part of responsible disclosure I have always thought disclosing actively exploited vulnerabilities immediately is warranted. There are exceptions but users need to know they are at risk. The downside is that if the attack is limited in nature, revealing vulnerability details exposes a wider user base. Its a no-win situation, but I almost always err toward giving people the ability to defend themselves. Keep in mind that this is only for active, critical exploitation – not unexploited new vulnerabilities. Disclosing those without time to fix only hurts users. Share: