Securosis

Research

Building an Enterprise Application Security Program: Recommendations

Our goal for this series is not to cover the breadth and depth of an entire enterprise application security program – most of you have that covered already. Instead it is to identify the critical gaps at most firms and offer recommendations for how to close them. We have covered use cases and pointed out gaps; now it’s time to offer recommendations for how to address the deficiencies. You will notice many of the gaps noted in the previous section are byproducts of either a) attackers exposing soft spots in security; or b) innovation with the cloud, mobile, and analytics changing the boundaries of what is possible. Core Program Elements Identity and Access Management: Identity and authorization mapping form your critical first line of defense for application security. SAP, Oracle, and other enterprise application vendors offer identity tools to link to directory services, help with single sign-on, and help map authorizations – key to ensuring users only get data they legitimately need. Segregation of duties is a huge part of access control programs, and your vendor likely covers most of your needs from within the platform. But there is an over-reliance on basic services, and while many firms have stepped up to integrate multiple identity stores with federated identity, attackers have shown most enterprises need to improve in some areas. Passwords: Passwords are simply not very good as a security control, and password rotation has never been proven to actually increase security; it turns out to actually be IT overhead for compliance’s sake. Phishing has proven effective for landing malware on users’ machines, enabling subsequent compromises, so we recommend two-factor authentication – at least for all administrative access. 2-factor is commonly available and can be integrated out-of-band to greatly increase the security of privileged accounts. Mobile: Protecting your users running your PCs on your network behind your firewalls is simply old news. Mobile devices are a modern – and prevalent – interface to enterprise applications. Most users don’t wait for your IT department to make policy or supply devices – they go buy their own and start using them immediately. It is important to consider mobile as an essential extension of the traditional enterprise landscape. These ‘new’ devices demand special consideration for how to deploy identity outside your network, how to _de-_provision users who have leave, and whether you need to quarantine data or apps on mobile devices. Cloud or ‘edge’ identity services, with token-based (typically SAML or OpenID) identity and mobile application management, should be part of your enterprise application security strategy. Configuration and Vulnerability Management: When we discussed why enterprise applications are different we made special mention several deficiencies in assessment products – particularly their ability to collect necessary information and lack of in-depth policies. But assessment is still one of the most powerful tools at your disposal, and generally the mechanism for validating 65% of security and compliance policies. It helps automate hundreds of repetitive, time-consuming, and highly technical system checks. We know it sounds cliche, but this really does save compliance and security teams time and money. These tools come with the most common security and compliance policies embedded to reduce custom development, and most provide a mechanism for non-technical stakeholders to obtain the technical data they need for reporting. You probably have something in place already, but there is a good chance it misses a great deal of what tools designed specifically for your application could acquire. We recommend making sure your product can obtain data, both inside and outside the application, with a good selection of policies specific to your key applications. A handful of generic application policies are a strong indicator that you have the wrong tool. Data Encryption: Most enterprise applications were designed and built with some data encryption capabilities. Either the application embeds its own encryption library and key management system, or it leverages the underlying database encryption engine to encrypt specific columns – or entire schemas – of data. Historically there have been several problems with this model. Many firms discovered that despite encrypted data, database indices and transaction logs contained and leaked unencrypted information. Additionally, encrypted data is stored in binary format, making it very difficult to calculate or report across. Finally, encryption has created performance and latency issues. The upshot is that many firms either turned encryption off entirely or removed it on temporary tables to improve performance. Fortunately there is an option which offers most of the security benefits without the downsides: transparent data encryption. It works underneath the application or database layer to encrypt data before it is stored on disk. It is faster that column encryption, transparent so no application layer changes are required, and avoids the risk of accidentally leaking data. Backups are still protected and you are assured that IT administrators cannot view readable data from disk. We recommend considering products from several application/database vendors and some third-party encryption vendors. Firewalls & Network Security: If you are running enterprise applications, you have firewalls and intrusion detection systems in place. And likely you also have next-generation firewalls, web application firewalls, and/or data loss prevention systems protecting you applications. Because these investments are already paid for and in place, they tend to be the default answer to any application security question. The law of the instrument states that if all you have is a hammer, everything looks like a nail. The problem is that these platforms are not optimal for enterprise application security, but they are nonetheless considered essential because every current security job falls to them. Unfortunately they do a poor job with application security because most of them were designed to detect and address network misuse, but they do not understand how enterprise applications work. Worse, as we shift ever more toward virtualization and the cloud, physical networks go away, making them less useful in general. But the real issue is that a product which was not designed to understand the application cannot effectively monitor its use or function. We recommend looking at

Share:
Read Post

New Research Paper: Secure Agile Development

Security teams are tightly focused on bringing security to applications, and meeting compliance requirements in the delivery of applications and services. On the other hand job #1 for software developers is to deliver code faster and more efficiently, with security a distant second. Security professionals and developers often share responsibility for security, but finding the best way to embed security into the software development lifecycle (SDLC) is not an easy challenge. Agile frameworks have become the new foundation for code development, with an internal focus on ruthlessly rooting out tools and techniques that don’t fit this type of development. This means secure development practices, just like every other facet of development, must fit within the Agile framework – not the other way around. This paper offers an outline for security folks to understand development teams’ priorities and methodologies, and practical ways to work together within the Agile methodology. Here is an excerpt: Over the past 15 years, the way we develop software has changed completely. Development processes evolved from Waterfall, to rapid development, to extreme programing, to Agile, to Agile with Scrum, to our current darling: DevOps. Each evolutionary step was taken to build better software by improving the software building process. And each step embraced changes in tools, languages, and systems to encourage increasingly agile processes, while discouraging slower and more cumbersome processes. The fast flux of development evolution gradually deprecated everything that impeded agility … including security. Agile had an uneasy relationship with security because its facets which promoted better software development (in general) broke existing techniques for building security into code. Agile frameworks are the new foundation for code development, with an internal focus on ruthlessly rooting out tools and techniques that don’t fit the model. So secure development practices, just like every other facet of development, must fit within the Agile framework – not the other way around. We are also proud that Veracode has asked to license this content; without support like this we could not bring this quality research to you free of charge without registration. As with all our research, if you have questions or comments we encourage you to comment on the blog so open discussion can help the community. For a copy of the research download the PDF, or get a copy from our research library page on Secure Agile Development. Share:

Share:
Read Post

Building an Enterprise Application Security Program: Security Gaps

This post will discuss the common security domains with enterprise applications, areas where generalized security tools lack the depth to address application and database specific issues, and some advice on how to fill in the gaps. But first I want to announce that Onapsis has asked to license the content of this research series. As always, we are pleased when people like what we write well enough to get behind our work, and encourage our Totally Transparent Research style. With that, on with today’s post! Enterprise applications typically address a specific business function: supply chain management, customer relations management, inventory management, general ledger, business performance management, and so on. They may support thousands of users, tie into many other application platforms, but these are specialized applications with very high complexity. To understand the nuances of these systems, the functional components that comprise an application, how they are configured, and what a transaction looks like to that application takes years of study. Security tools also often specialize as well, focusing on a specific type of analysis – such as malware detection – and applying it in particular scenarios such as network flow data, log files, or binary files. They are generally designed to address threats across IT infrastructure at large; very few move up the (OSI) stack to look at generic presentation or application layer threats. And fewer still actually have any knowledge of specific application functions to understand a complex platform like Oracle’s Peoplesoft of SAP’s ERP systems. Security vendors pay lip service to understanding the application layer, but their competence typically ends at the network service port. Generic events and configuration data outside applications may be covered; internals generally are not. Let’s dig into specific examples: Understanding Application Usage The biggest gap and most pressing need is that most monitoring systems do not understand enterprise applications. To continuously monitor enterprise applications you need to collect the appropriate data and then make sense of it. This is a huge problem because data collection points vary by application, and each platform speaks a slightly different ‘language’. For example platforms like SAP speak in codes. To monitor SAP you need to understand SAP operation codes such as T-codes, and there are a lot of different codes. Second you need to know where to collect these requests – application and database log files generally do not provide the necessary information. As another example most Oracle applications rely heavily on stored procedures to efficiently process data within the database. Monitoring tools may see a procedure name and a set of variables in the user request, but unless you know what operation that procedure performs, you have no idea what is happening. Again you need to monitor the connection between the application platform and the database because audit logs do not provide a complete picture of events; then you need to figure out what the query, code, or procedure request means. Vendors who claim “deep packet inspection” for application security skirt understanding how the application actually works. Many use metadata (including time of day, user, application, and geolocation) collected from the network, possibly in conjunction with something like an SAP code, to evaluate user requests. They essentially monitor daily traffic to develop an understanding of ‘normal’, then attempt to detect fraud or inappropriate access without understanding the task being requested. This is certainly helpful for compliance and change management use cases, but not particularly effective for fraud or misuse detection. And it tends to generate false positive alerts. Products designed to monitor applications and databases actually understand their targeted application, and provide much more precise detection and enforcement. Building application specific monitoring tools is difficult and specialized work. But when you understand the application request you can focus your analysis on specific actions – order entry, for example – where insider fraud is most prevalent. This speeds up detection, lessens the burden of data collection, and makes security operations teams’ job easier. Application Composition Throughout this research we use the term ‘database’ a lot. Databases provide the core storage, search, and data management features for applications. Every enterprise application relies on a database of some sort. In fact databases are complex applications themselves. To address enterprise application security and compliance you must address many issues and requirements for both the and the application platforms. Application Deployments We seldom see two instances of the same application deployed the same. They are tailored to each company’s needs, with configuration and user provisioning to support specific requirements. This complicates configuration and vulnerability scanning considerably. What’s more, application and database assessment scans are very different from typical OS and network assessments, requiring different evaluation criteria to assess suitability. The differences lie in both how information is collected, and the depth and breadth of the rule set. All assessment products examine software revision levels, but generic assessment tools stop at list vulnerabilities and known issues, based exclusively on software versions. Understanding an application’s real issues requires a deeper look. For example test and sample applications often introduce back doors into applications, which attackers then exploit. Software revision level cannot tell you what risks are posed by vulnerable modules; only a thorough analysis of a full software manifest can do that. Separation of duties between application, database, and IT administrators cannot be determined by scanning a network port or even hooking into LDAP – it requires interrogation of applications and persistent data storage. Network configuration deficiencies, weak passwords and public accounts, all easily spotted by traditional scanners – provided they have a suitable policy to check – but scanners do not discover data ownership rights, user roles, whether auditing is enabled, unsafe file access rights, or dozens of other well-known issues. Data collection is the other major difference. Most assessment scans offer a basic network port scanner – for cases where agents are inappropriate – to interrogate the application. This provides a quick, non-invasive way to discover basic patch information. Application assessment scanners look for application specific settings, both on disk

Share:
Read Post

Building an Enterprise Application Security Program: Use Cases

This post will discuss security and compliance use cases for an enterprise application security program. The following are the main issues enterprises need to address with enterprise application management, in no particular order. None of these drivers are likely to surprise you. But skimming the top-line does not do the requirements justice – you also need to understand why enterprise applications offer different challenges for data collection and analysis, to fully appreciate why off-the-shelf security tools leave coverage gaps. Compliance Compliance with Sarbanes-Oxley and the Payment Card Industry Data Security Standard (PCI-DSS) remain the primary drivers for security controls for enterprise applications. Most compliance requirements focus on baselining ‘in-scope’ applications – essentially configuration assessments – to ensure known problem areas are periodically verified as compliant. Compliance controls typically focus on issues of privileged user entitlements (what they can access), segregation of duties, prompt application of security patches, configuring the application to promote security, and consistency across application instances. These assessment scans demonstrate that each potential issue has a documented policy, that the policy is regularly tested, and that the company can produce a report history to show compliance over time. The audience for this data is typically the internal audit team, and possibly third-party auditors. Change management & policy enforcement Beyond external compliance requirements enterprises adopt their own policies to reduce risk, improve application reliability, and reduce potential for fraud. These policies ensure that system and IT administrators perform their jobs – both to catch mistakes and to help detect administrative abuse of assigned privileges. Examples include removal of unneeded modules which contain known vulnerabilities, tracking all administrative changes, alerting on – and possibly blocking – use of inappropriate management tools, disabling IT administrators’ access to application data, and detecting users or permissions which could provide ‘backdoor’ access to the system. All of which means these policies are specific to an individual organization, are more complex, and require a great deal more than application assessment to verify. Effective enforcement requires a combination of assessment, continuous monitoring, and log file analysis. And let’s not beat around the bush – these policies are established to keep administrators – of IT, databases, and applications – honest. The audience for these reports is typically internal audit, senior IT management, automated change management systems, and the security group. Security A debate has raged for 15 years about whether the greatest threat to IT is external attackers or malicious insiders. For enterprise applications the distinction is less than helpful – both groups pose serious threats. Further muddying the waters, external parties seek privileged access, so they may be functioning as privileged insiders even when that is an impersonation. Beyond attack detection, common security use cases include quarterly ‘reconciliation’ review, watching for ad hoc operations, requests for sensitive data at inappropriate times or from suspicious locations, and even general “what the heck is going on?” visibility into operations. These operations are commonly performed by users or application administrators. Of all the use cases we have listed, identifying suspicious acts in a sea of millions of normal transactions is the most difficult. More to the point, while compliance and policy enforcement are preventive operations, security is the domain of monitoring usage in near-real time. These features are not offered within the application or supporting database platform, but provided through external tools – often from the platform vendor. Transaction verification As more enterprise applications serve external users through web interfaces, the problem of fraud growing. Every web-facing service faces spoofing, tampering, and non-repudiation attacks, and often (and worst) SQL injection. When successful these attacks can create bogus transactions, take partial control of the supporting database, and cause errors. But unlike general security issues, these attacks are designed to create fraudulent transactions and constructed to look like legitimate traffic. How companies detect these situation varies – some firms have custom macros or procedures that look for errors after the fact, while others use third-party monitoring and threat intelligence services to detect attacks as they occur. These tools are designed to detect users who attempt to make the application behave in an unusual manner – relying on metadata, heuristics, and user/device attributes to uncover misuse by application users. Use of sensitive information Most enterprises monitor the use of sensitive information. This may be for compliance, as with payment data access or sensitive personal information, or it may be part of a general security policy. Typical policies cover IT administrators accessing data files, users issuing ad hoc queries, retrieval of “too much” information, or any examination of restricted data elements such as credit card numbers. All the other listed use cases are typically targeted at specific user or administrative roles, but policies for information usage apply to all user groups. They are constructed to define uses cases which are not acceptable, and alert or block them. These controls may exist as part of the application logic, but are typically embedded into the database logic (such as through stored procedures), or provided by a third-party monitoring/masking tool deployed as a reverse proxy for the database. The next post will detail how enterprise applications differ from other platforms, and how those differences create security gaps for off-the-shelf tools. Share:

Share:
Read Post

Friday Summary; October 31, 2014

I was at Intel’s Focus conference earlier this week. Intel basically held a McAfee coming-out party, and announced that the security practices of both firms will henceforth be run under the single umbrella of Intel Security. Not much to report on that, but I spoke to more customers at this event than at any other vendor event. And they were chatty, which is nice. But something is troubling me. Do you know what they did not mention as a problem? Mobile. Nope. The biggest surprise of the week was hearing security practitioners and CISOs talk about the threat of the IoT (Internet of Things), without even mentioning mobile. I am still surprised, because a) mobile is really here, b) security of mobile data is a problem on most devices, c) mobile app controls and spotty authentication are still an issue, and d) the market has yet to embrace a good model for control. IoT does not even feel real yet, but the security practitioners I heard speak are currently dealing with threats to Point of Sale terminals, medical devices, cars, and a whole bunch of devices we have used for a long time, but where the current generation includes sophisticated processors and Internet connectivity. Still, IoT is your biggest concern? Really? This will be the one of the shorter Friday Summaries I have written because … it’s here. The puppy I predicted would be landing in my home has arrived. Early, in fact. I am sure it’s because the breeder was exhausted by him. He is slightly ornery, possessed of limitless energy, and fearless. Which means he is into everything all the time. Say hello to ‘Satchmo’: I don’t usually talk about my pets much on this blog, but it has been years since we had a new puppy in the house, and you forget all the lifestyle changes that come with a new puppy. Plus he’s very cute, and seems to get along with everyone great. He has only been here a short time but he’s worn me out. And my wife. And my adult Boston. And everything else that lives here … except the Boxer. Boxers never get tired, so I think the rest of us are going to take a nap while those two play. Happy Halloween all! Halloween on a Friday is the best, so have fun! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian and Chris Eng will talk integrating security into Agile next week. Favorite Securosis Posts Adrian Lane: Incite 10/29/2014: Short Memory. I am actually FAV-ing my “Card of the Sith” Incite in this week’s post. Rich: [Building an Enterprise Application Security Program New Series. Ho boy, is this a big topic. Adrian jumps into one of the most painful issues for enterprises to deal with: internal apps. Mike Rothman: Firestarter: It’s All in the Cloud. I had fun recording this week’s Firestarter. Though we did miss Adrian. There was no one to keep Rich and me on track! Other Securosis Posts Building an Enterprise Application Security Program: Use Cases. Apple Security and Privacy Updates. New Research Paper: Trends in Data Centric Security. Old School (Computer). Favorite Outside Posts Adrian Lane: Challenges With Randomness In Multi-tenant Linux Container Platforms. Containers seem to have caught fire, and I expect them to be the ‘struts’ of this generation. But stressing any hot new approach turns up systemic flaws. A good discussion by James Bayer. Rich: Facebook Open Sources Host Monitoring Tool, Increases Internet Defense Prize. This is interesting. I did an interview on the tool, based on a high-level description (trust me – I warned the reporter I would need to see it working for a real assessment). It sounds like a Chef/Puppet competitor. But this gathers different information, which is more security relevant, and then enables you to query it like a database. That is very interesting. Might have to play with it! Mike Rothman: SHE’S A WRECK. What a courageous post by aloria, baring her issues with brutal honesty and candor. Thankfully she made it through, but understand that her bipolar disorder is a daily battle. Rarely do we get to see the people behind the avatars, the unvarnished challenge of being imperfect and human. as we all are. Pepper: AT&T, Verizon Using ‘Perma-Cookies’ to Track Customer Web Activity. I didn’t think I needed a VPN but I am now considering paying for Cloak. Research Reports and Presentations Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Top News and Posts UPnP Devices Used in DDoS Attacks Chip & PIN vs. Chip & Signature Adobe’s e-book reader sends your reading logs back to Adobe–in plain text. *sigh* Automated NoSQL exploitation with NoSQLMap CurrentC for mobile payments and exclusivity CurrentC site hacked Alleged Dropbox hack underlines danger of reusing passwords Blog Comment of the Week This week’s best comment goes to Pat Bitton, in response to Old School. I always hark back to the operating code for dBase II and WordStar both fitting on a single 360K floppy. Share:

Share:
Read Post

New Research Paper: Trends in Data Centric Security

The concept of Data Centric Security is not new, but its advantages are only now becoming clear. As customers embrace disruptive technologies – cloud, mobile, NoSQL – where the availability and effectiveness of security controls are in question, Data Centric Security is an approach to securing data regardless of where it is moved. DCS is a way to leverage these new technologies without compromising data security, integrity, or compliance. This research was prompted by increasingly frequent inquiries about how to secure “big data” clusters. The cost, complexity, and lack of packaged solutions have left many people looking for options. You can compartmentalize NoSQL servers so only a select few people and applications can access them, but then you fail to fully leverage the investment – which makes isolation a non-starter in most scenarios. That is the potential of Data Centric Security: it focuses security controls on data rather than servers or supporting infrastructure. This way the database is securely available to everyone who can use it legitimately. This research delves into what Data Centric Security is, the challenges it addresses, and technologies to support customer use cases. We hope you find this research useful, and consider DCS as an alternative to traditional infrastructure security. I am incredibly happy to announce that Intel Services has agreed to license this research paper – which you can download here (PDF) or visit the research library landing page here – and that we will also present a webcast on Data Centric Security, tentatively scheduled for November 18th, 2014. Sign up if you are interested. Thanks again to Intel for their support of this research! Share:

Share:
Read Post

Building an Enterprise Application Security Program [New Series]

Over the last couple months I have had many similar conversations on enterprise application security: customers identify gaps in their security program, are unaware of the availability of certain types of solutions, or simply don’t believe that certain solutions deliver their advertised value. But I expect issues when speaking to a company who wants to implement advanced security on a Hadoop database, where technology simply may not exist to deliver the security and performance required. It is altogether different when talking about SAP or Oracle financials. These are mature platforms, often in place for more than a decade, so you would expect every aspect to be covered. Surprisingly that is often not the case. There are many reasons for these security gaps. Companies often invest in generic assessment or configuration analysis tools, which don’t actually provide an in-depth view of application configuration settings or best practices. Perhaps they were told their SIEM would collect all application logs but they don’t contain the necessary information to evaluate user actions, or they are simply too verbose to collect. The application vendors all provide lists of security best practices, but don’t list anything they do not sell, nor advise customers to uninstall unneeded components to reduce attack surface. Security teams know little about how application platforms work so they cannot independently identify which deployment models would work, and IT staff is not likely to volunteer suggestions that will require them to do more work. Finally, the largest issue is that many approaches are simply unsuitable for large enterprise applications because they will break the application, limit usability, or degrade performance, none of which are acceptable. These issues contribute to security and compliance gaps at most firms. Supply chain management, customer relationship management, enterprise resource management, business analytics, and financial transaction management, are all multi-billion dollar application platforms unto themselves. We are beyond explaining why enterprise applications need security to protect these investments – it is well established that insiders and persistent adversaries target these applications. Companies invest heavily in these applications, hardware to run them, and teams to keep them up and running. They perform extensive risk analysis on their business implications and the costs of downtime. And in many cases their security investments are a byproduct of these risk profiles. Application security trends in the 1-2% range of total application investment, but I cannot say large enterprises don’t take security seriously – they spend millions and hire dedicate staff to protect these platforms. That said, their investments are not always optimal – enterprises may bet on solutions with limited effectiveness, without a complete understanding of the available options. It is time for a fresh look. To fill some of these gaps we are starting a new series on Building an Enterprise Application Security program. We spend a lot of time on advanced technologies on the Securosis blog: variants of monitoring, auditing, assessment, threat management, application security, and so on – but we have never pulled all these facets together for companies to assemble into an enterprise application security program. Or goal is to discuss specific security and compliance use cases for large enterprise applications, highlight gaps, and explain some application-specific tools to address these issues. This will not be an exhaustive examination of enterprise application security controls, nor an examination of generic security platforms – instead we will offer a focused summary of the most common deficiencies, with suggestions for what to do about them. The remainder of this series will cover the following: Needs: Use Cases Compliance (SOX, PCI, etc.) and internal audit reporting Transaction verification Use of sensitive information Security (insider and external threats) Change management & policy enforcement Gaps: What Works and What Doesn’t Why enterprise applications are different SAP: special issues with this poster child for enterprise applications Security and compliance gaps with IAM, encryption, and data encryption Inventory, discovery, and assessment Network monitoring deficiencies Conventional application and database layer protection Skills and priorities Program Elements Assessment: discovery and configuration analysis Patching and configuration management (environment, application, database, & modules) Application and database monitoring Management frameworks and policy enforcement Logging, auditing, and compliance reports Additional recommendations Our next post will discuss use cases and problems firms need to address, which we will use to frame our subsequent discussion of security gaps. Share:

Share:
Read Post

Friday Summary: October 17, 2014

Ever tried to count to a billion? Don’t bother. The average human lifespan is about 2.5 billion seconds, so you’d waste half your life trying. But that may help put into perspective Databrick’s latest announcement that they were able to sort 10 trillion records in four hours with the Spark platform. That’s three times faster than the previous record, with one-tenth the number of server nodes. Or perhaps you noticed that Amazon added full JSON support to DynamoDB, so you can easily inject JSON directly into the cluster. Or maybe you saw that Data Torrent now supports analytics on the incoming data stream. Or perhaps you were pleased to see ParStream’s distributed approach specifically geared to the Internet of Things. None of these individual events is all that newsworthy. But the scale and pace of innovation across hundreds of different NoSQL platforms is. I hAve said many times here that NoSQL is the database of the future, but I don’t think I have stressed enough that no matter what you want to do with a database, there is a flavor of NoSQL designed for your use case. And even if it’s not a perfect match, the flexibility and customization possible with most NoSQL platforms can make it work. Size, scale, and speed – at cost unimaginable just a few years ago. What does this have to do with security? I no longer speak to customers with a single Hadoop installation of 20 or so nodes. The number of nodes is climbing, and the number of NoSQL databases running in parallel at customer sites is climbing as well. The size of these clusters is beginning to break our security recommendations from the last few years. In some cases security goals require an architectural shift. In other cases I am at a loss to provide recommendations – I am not certain that security controls exist to accommodate the size and velocity of some clusters. Hang on to your seats because it is getting interesting in the world of NoSQL security. Butterflies. Not that you care, but there are a lot of butterflies in Phoenix this year. And my wife and I have planted a huge number of shrubs that attract butterflies, so we are fortunate to have swarms of them in the yard the last three weeks. Yellow ones, green ones, black with patches of amber and brilliant blue dots, giant black and yellow ones, some orange, and others orange with black spots. Dozens or even hundreds of them in the back yard on any given day. Colors that match New England fall leaves, but this is living art with a delicacy hard to imagine until you see them defying the breeze. It is one of the most beautiful sites I have ever seen. If only I could capture it on video … On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in TidBITS #1: You Are Apple’s Greatest Security Challenge. Rich in TidBITS #2: Apple and Google Spark Civil Rights Debate. Favorite Securosis Posts David Mortman: An Example of Gratitude. Adrian Lane: The photo in Mike’s post on Competing made coffee spurt through my nose, I laughed so hard, but my favorite this week is Rich’s post on Physicality because he totally nails my experience and tribulations with writing! Other Securosis Posts Incite 10/15/2014: Competing. Favorite Outside Posts Rich: Rethinking the Security “Con”. Great rant by Shack about security conferences. There are too many, saying the same stuff. I like his suggestions toward the end, especially having everyone share 5 things they learned. That would be awesome. Mike Rothman: Before the Startup. With so much money flowing into everything ‘cyber’ we have lots of folks who want to start companies. They should read this post. It is a different counterintuitive world. It’s like riding a roller coaster. Every day. That doesn’t mean don’t do it, but go in with your eyes open. David Mortman: Homebrew Incident Response. Adrian Lane: Wake up to a POODLE puddle. Kudos to Martin for coming up with a list of links of everything you need to know about POODLE attacks, and my favorite vulnerability logo for this issue! Research Reports and Presentations Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Top News and Posts Alleged Dropbox hack underlines danger of reusing passwords Laura Poitras on the Crypto Tools That Made Her Microsoft, Adobe Push Critical Security Fixes Government Set Up A Fake Facebook Page In This Woman’s Name What you need to know about POODLE/SSL 3.0 vulnerability Apple Pay Setup, Functionality Leaked in New Screenshots Blog Comment of the Week This week’s best comment goes to Anonymous, saying something about buying Viagra on the cheap. That’s great news – it means blog comments are working again. Thanks for testing, spammers! Share:

Share:
Read Post

Friday Summary: October 3, 2014 cute puppy edition

I was going to write more this week on Apple Pay security and it use of tokenization because more details have come out, but I won’t bother because TUAW beat me to it. They did a good job explaining how tokenization is used by Apple, and went on to discuss one of the facets I have been trying to get details on: the CCV/CVV code. Apple is dynamically generating a new CVV for each transaction, which can be verified by the payment processor to ensure it is coming from an authorized device. In a nutshell: fingerprint scan to verify the user is present, a token that represents the card/device combination, and a unique CVV to verify the device in use. That is not just beyond magstripes – it is better than EMV-style smart cards. No wonder the banks were happy to work with Apple. Tip of the cap to Yoni Heisler for a well-written article. It is interesting to watch events unfold when you knew exactly how they would occur beforehand. Try as you might, you cannot avoid the inevitable, even when you know it’s coming a long ways off. In this case 6 months ago a very dear friend – someone we had not spoken with in quite a while – called my wife and asked her to have lunch. The first thing that popped into my mind was, “Oh crap, we’re getting a new puppy!” See, this friend is a breeder of Boston Terriers, and we have owned many of her dogs over the years. And she was thinking of breeding two of her stock, and she will be looking for good homes to place them in. I guarantee you that landing in the Lane household is the puppy equivalent of winning the lottery – our home is a bit sought after by many dog breeders and rescue shelters. And this friend and my wife are both aware that our current Boston is 12 – he is still feisty but clearly in elder statesman territory. Keep in mind that none of the above factoids are ever discussed. No need. But you don’t have to be prescient to see what’s coming. Now that the puppies are on the ground, my wife was invited back to “help socialize” a litter of puppies with a cuteness index of 11. So I have no doubt that within several weeks we will be hearing the all-too-familiar nighttime puppy running outside before it wets the blanket again. Who needs sleep? I need to proactively pick out some puppy names! As Mike’s weekly Incite discussed, it has been a dizzying week for all of us here, but we have come out the other side unscathed. And next week will be no different. I am presenting at the Akamai Edge conference in Miami, so if you’ll be in town let me know! Now let’s move on to the summary… Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s webcast on Hadoop Security. James Arlen’s Derbycon talk Favorite Securosis Posts Adrian Lane: Stranger in my own town. A glimpse into what it’s like to be Mike. A good post and a feel for what it has been like this year. David Mortman: Security and Privacy on the Encrypted Network: The Future is Encrypted. Mike Rothman: Friday Summary: September 26, 2014. Slim pickings this week, but I like the round-up of stuff on Adrian’s mind. Always entertaining. Favorite Outside Posts David Mortman: Four Interactions That Could Have Gone Better. Adrian Lane: Top 10 Web Hacking Techniques of 2013 – OWASP AppSecUSA 2014. My fave this week is a video from last week’s OWASP event – I was not able to go this year but it’s always a great con. Mike Rothman: The Truth About Ransomware. Great post by Andrew Hay about the fact that you’re on your own if you get infected with ransomware. You might get your files back, you might not. So make sure you back up the important stuff. And don’t click things. Truth. Research Reports and Presentations Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Top News and Posts NoSQL SSJI Authentication Bypass. Today’s laboratory hack, tomorrow’s Hadoop data breach. The shockingly obsolete code of bash Cops Are Handing Out Spyware to Parents—With Zero Oversight. Mind. Blowingly. Stupid. More Evidence Found in JPMorgan Chase Breach (Updated) Apple Releases Patches for Shellshock Bug Inside the NSA’s Private Cloud OpenVPN vulnerable to Shellshock Bash vulnerability A Comprehensive Outline of the Security Behind Apple Pay EC2 Maintenance Update II Oracle, Cisco step up cloud battle Apache Drill is ready to use and part of MapR’s distro. SQL queries for Hadoop. Three critical changes to PCI DSS 3.0 Blog Comment of the Week This week’s best comment goes to nobody because our comment system is broken, but we’re working on it. Promise! Share:

Share:
Read Post

Friday Summary: September 26, 2014

I have a great job. The combination of extended coverage areas, coupled with business to tech, and everything in between, makes it so. In this week alone I have talked to customers about Agile development and process adjustments, technical details of how to deploy masking for Hadoop, how to choose between two SIEM vendors, and talked to a couple vendors about Oracle and SAP security. The breadth of stuff I am exposed to is awesome. People often ask me if I want to go back to being a CTO or offer me VP of Engineering positions, but I cannot imagine going back to just focusing on one platform. I don’t get my hands as dirty, but in some ways it is far more difficult to learn nuances of half a dozen competitive product areas than jus one. And what a great time to be neck deep in security … so long as I don’t drown in data. Learning about DevOps is fascinating. Talking to people who are pushing forward with continuous integration and deployment, and watching them break apart old dev/QA/IT cycles, provides a euphoric glimpse at what’s possible with Agile code development. Then I speak with more traditional firms, still deeply embedded in 24-month waterfall development. The long tail (and neck, and back) of their process feels like a cold bucket of reality – I wonder if a significant percentage of companies will ever be agile. When I contrast Why Security Automation is the Way Forward with mid-sized enterprises, I get another cold slap from reality. I speak with many firms who cannot get servers patched every other quarter. Security patches for open source will come faster than before, but organizational lag holds firm. It is clear that many firms have a decade-long transition to more agile processes in store, and some will never break down the cultural barriers between different teams within their companies. Gunnar’s recent To Kill A Flaw post is excellent. Too good, in fact – his post includes several points that demand their own blog entries. One of the key points Gunnar has been making lately, especially in light of the nude celebrity photo leaks, is that credentials are a “zero day” attack. You need to keep that in mind when designing identity and access management today. If a guessed password provides a clear way in, you need to be able to live with that kind of 0-day. That is why we see a push away from simple passwords toward identity tokens, time-limited access, and risk-based authorization on the back end. Not only is it harder to compromise credentials, the relative risk score moves from 10 to about 4 because the scope of damage is lessened. A family member who is a bit technically challenged asked me “Is the Bash Bug Bad?” “Bad. Bad-bad-bad!” I left it at that. I think I will use that answer for press as well. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on Chip and Pin. Rich quoted in Denver Post on How to Protect Your Data in the Cloud Favorite Securosis Posts Mike Rothman: Secure Agile Development: Building a Security Tool Chain. The testing process is where the security gets real. Great series from Adrian and Rich. Adrian Lane: Why the bash vulnerability is such a big deal (updated). Excellent overview by Rich on the bash vulnerability hyped as ‘shellshock’. Other Securosis Posts Why Amazon is Rebooting Your Instances (Updated). Hindsight FTW. Summary: Run Free. Secure Agile Development: Process Adjustments. Incite 9/17/2014: Break the Cycle. Firestarter: Apple Pay. Fix Something. Favorite Outside Posts Mike Rothman: The Pirate Bay Operations: 21 Virtual Machines Are Used To Run The File-sharing Website. This cloud thing might not be a fad. This is how you take an international network of stuff and move it quickly… And the torrents are pleased. Adrian Lane: Can Static Analysis replace Code Reviews? The case for security … this shows why old-fashioned manual scans cannot be fully replaced by static analysis. It also shows the need to train developers on what type of flaws to look for. Good post! Research Reports and Presentations Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Top News and Posts Three critical changes to PCI DSS 3.0 Trustworthy Computing RSA Signature Forgery in NSS Data Masking Bundled with Cloudera, Hortonworks Apple releases iOS 8 with 56 security patches CloudFlare Introduces SSL Without Private Key SSL Issues with this Blog? by Branden Williams. Bash ‘shellshock’ bug is wormable Funds in Limbo After FBI Seizes Funds from Cyberheist. Not a new problem, just a new cause. Jimmy John’s Confirms Breach at 216 Stores Julian Sanchez on NSA reform. Home Depot’s Former Security Engineer Had a Legacy of Sabotage Ping Identity Scoops $35M To Authenticate Everywhere Blog Comment of the Week This week’s best comment goes to Andrew Hay, in response to Why the bash vulnerability is such a big deal (updated). As per a conversation I had with HD Moore, he loves to release the Metasploit modules as quickly as possible in an effort to eliminate pay-per-exploit companies from profiting off of a particular vuln. I kind of agree with him. Share:

Share:
Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.