A lot of our research is conceptual, so we like to wrap up with a scenario. This helps make the ideas a bit more tangible, and provides context for you to apply it to your particular situation. To illuminate how the Security Analytics Team of Rivals can work, let’s consider a scenario involving a high-growth retailer who needs to maintain security while scaling operations which are stressed by that growth. So far our company, which we’ll call GrowthCo, has made technology a key competitive lever, especially around retail operations, to keep things lean and efficient. As scaling issues
Let’s start with a rhetorical question: Can you really “manage” threats? Is that even a worthy goal? And how do you even define a threat. We’ve seen a more accurate description of how adversaries operate by abstracting multiple attacks/threats into a campaign. That intimates a set of interrelated attacks all with a common mission. That seems like a better way to think about how you are being attacked, rather than the whack a mole approach of treating every attack as a separate thing and defaulting to the traditional threat management cycle: Prevent (good luck), Detect, Investigate, Remediate.
As we described in the introduction to this series, security monitoring has been around for a long time and is evolving quickly. But one size doesn’t fit all, so if you are deploying a Team of Rivals they will need to coexist for a while. Either the old guard evolves to meet modern needs, or the new guard will supplant them. But in the meantime you need to figure out how to solve a problem: detecting advanced attackers in your environment. We don’t claim to be historians, but the concept behind Lincoln’s Team of Rivals (Hat tip
If you are going to be in San Francisco next week. Yes, next week. How the hell is the RSA Conference next week? Anyhow, don’t forget to swing by the Disaster Recovery Breakfast and say hello Thursday morning. Our friends from Kulesa Faul, CHEN PR, LaunchTech, and CyberEdge Group will be there. And hopefully Rich will remember his pants, this time.
Use of cloud services is common in IT. Gmail, Twitter, and Dropbox are ubiquitous; as are business applications like Salesforce, ServiceNow, and QuickBooks. But along with the basic service, customers are outsourcing much of application security. As more firms move critical back-office components such as SAP Hana to public platform and infrastructure services, those vendors are taking on much more security responsibility. It is far from clear how to assemble a security strategy for complex a application such as SAP Hana, or how to adapt existing security controls to an unfamiliar environment with only partial control. We have received a
Security monitoring has been a foundational element of most every security program for over a decade. The initial driver for separate security monitoring infrastructure was the overwhelming amount of alerts flooding out of intrusion detection devices, which required some level of correlation to determine which mattered. Soon after, compliance mandates (primarily PCI-DSS) emerged as a forcing function, providing a clear requirement for log aggregation – which SIEM already did. As the primary security monitoring technology, SIEM became entrenched for alert reduction and compliance reporting. But everything changes, and the requirements for security monitoring have evolved. Attacks have become much more sophisticated,
TL;DR: SaaS enables Zero Trust networks with pervasive encryption and access. Box vendors lose once again. It no longer makes sense to run your own mail server in your data center. Or file servers. Or a very long list of enterprise applications. Unless you are on a very very short list of organizations. Running enterprise applications in an enterprise data center is simply an anachronism in progress. A quick peek at the balance sheets of the top tier Software as a Service providers shows the transition to SaaS continues unabated. Buying and maintaining enterprise applications, such as mail servers,
In the first two posts of this Dynamic Security Assessment series, we delved into the limitations of security testing and then presented the process and key functions you need to implement it. To illuminate the concepts and make things a bit more tangible, let’s consider a plausible scenario involving a large financial services enterprise with hundreds of locations. Our organization has a global headquarters on the West Coast of the US, and 4 regional headquarters across the globe. Each region has a data center and IT operations folks to run things. The security team is centralized under a global CISO,
This post will discuss the foundational elements of an application security program for SAP HCP deployments. Without direct responsibility for management of hardware and physical networks you lose the traditional security data capture points for traffic analysis and firewall technologies. The net result is that, whether on PaaS or IaaS, your application security program becomes more important than ever as what you have control over. Yes, SAP provides some network monitoring and DDoS services, but your options are are limited, they don’t share much data, and what they monitor is not tailored to your applications or requirements. Any application
This post will discuss several keys differences in application architecture and operations – with a direct impact on security – which you need to reconsider when migrating to cloud services. These are the areas which make operations easier and security better. As companies move large business-critical applications to the cloud, they typically do it backwards. Most people we speak with, to start getting familiar with the cloud, opt for cheap storage. Once a toe is in the water they place some development, testing, and failover servers in the cloud to backstop on-premise systems. These ar less critical than production servers, where firms