Wrangling Backoffice Security in the Cloud Age

Over a year ago we first published our series on Tidal Forces: The Trends Tearing Apart Security As We Know It. We called out three megatrends in technology with deep and lasting impact on security practice: Endpoints are different, often more secure, and frequently less open. If we look at the hardening of operating systems, exemplified by the less-open-but-more-secure model of Apple’s iOS, the cost of exploiting endpoints is trending much higher. At least it was before Meltdown and Spectre, but fortunately those are (admittedly major) blips, not a permanent direction. Software as a Service (SaaS) is the new back office. Organizations continue to push more and more of their supporting applications into SaaS – especially capabilities such as document management, CRM, and ERP which aren’t core to their mission. Infrastructure as a Service (IaaS) is the new data center. The growth of public IaaS has exceeded even our aggressive expectations. It’s the home of most new applications, and a large number of organizations are shifting existing application stacks to IaaS – even when it doesn’t make sense. The fundamental precept of the “Tidal Forces” concept is that these trends act like gravity wells. We are all pulled inexorably towards them, at a rate that increases as we get closer – until we are ripped apart because some parts of the organization move more quickly while others are left behind, but teams like infrastructure and security are must attempt to support both ends of the spectrum simultaneously. Since publication, nothing has dissuaded us from believing these trends will only continue to accelerate and increase internal pressures. This migration of the back office into an ever-growing menagerie of remote services has many practical security implications. It’s more than just losing physical control – different services have different capabilities, and they all demand new security management models, tools, and techniques. The more you try to force the lessons of the past into the future, the more painful the transition. It isn’t that we throw all our knowledge and skills away, but we need to translate them before we can provide security in the new environment. This short paper will highlight some of the top ways security operations are being affected, then offer recommendations for managing the problem over time. How the SaaS Transition Impacts Security Moving your most sensitive data to an outside provider quickly shatters the illusion that physical control matters any more. But the shift doesn’t absolve you of overall security accountability. The transition creates both advantages and challenges, with a wide range of variability depending on how you manage it. The biggest challenge with Software as a Service is the sheer range of capabilities across even similar-seeming providers. Some top-notch SaaS providers understand that major security incidents are existential threats to their business, so they invest heavily in security capabilities and features. Other companies are fast-moving startups which care more about customer acquisition than customer safety – but eventually they will learn, painfully. Aside from their inherent security, these services are all effectively remote applications, each with its own internal security models and capabilities which need to be managed. Risk assessment and platform knowledge are high priorities for security teams managing SaaS. It doesn’t help that these platforms are all inherently Internet accessible. Which mean your data can be too, if you fail to configure them properly. Nearly all the services default to secure options, but the news is filled with examples of… exceptions. Existing tools and techniques rarely apply directly or cleanly to the cloud. You don’t manage a firewall – instead you need to federate for identity management – and just about every traditional monitoring tool breaks. For example consider log management for monitoring and incident response. You generally only have access to the logs provided by your cloud platform, if any, and they are most likely in a custom format and are only accessible via API calls within the cloud provider’s user interface, or as data dumps. Planning on just sniffing ‘your’ traffic? Aside from having almost no context for it, ongoing adoption of TLS 1.3 forces you to drop to less secure encryption options (if they are even available) to capture traffic. Or you can engage in a man-in-the-middle attack against your own users, reducing security to improve monitoring. Last, and for some of you most important, is compliance. You are fully reliant on your SaaS provider’s compliance, and then need to ensure you configure and use everything correctly. With IaaS we can get around some of these restrictions, but with SaaS that usually isn’t an option. When a provider offers baseline compliance with a regulation or standard we call that compliance inheritance, but that only means their baseline is compliant – if you decide to make all your PII records publicly shareable… good luck with the auditors. Every new technology comes with tradeoffs. In the end our job as security practitioners is to decide whether any decision produces a net improvement or loss in risk, and how to best mitigate that risk to the level our organization desires. The cloud comes with tremendous potential security benefits – particularly outsourcing our applications and data to providers with far stronger incentive to keep it secure – but we need to select the right provider, determine the right configuration, and use the right security processes and tools to manage it all. Share:

Read Post

Container Security 2018: Logging and Monitoring

We close out this research paper with two key areas: Monitoring and Auditing. We want to draw attention to them because they are essential to security programs, but have received only sporadic coverage in security blogs and the press. When we go beyond network segregation and network policies for what we allow, the ability to detect misuse is extremely valuable, which is where monitoring and logging come in. Additionally, most Development and Security teams are not aware of the variety of monitoring options available, and we have seen a variety of misconceptions and outright fear of the volume of audit logs to capture, so we need to address these issues. Monitoring Every security control discussed so far can be classed as preventative security. These efforts remove vulnerabilities or make them hard to exploit. We address known attack vectors with well-understood responses such as patching, secure configuration, and encryption. But vulnerability scans can only take you so far. What about issues you are not expecting? What if a new attack variant gets by your security controls, or a trusted employee makes a mistake? This is where monitoring comes in: it is how you discover unexpected problems. Monitoring is critical to any security program – it’s how you learn what works, track what’s really happening in your environment, and detect what’s broken. Monitoring is just as important for container security, but container providers don’t offer it today. Monitoring tools work by first collecting events, then comparing them to security policies. Events include requests for hardware resources, IP-based communication, API requests to other services, and sharing information with other containers. Policy types vary widely. Deterministic policies address areas such as which users and groups can terminate resources, which containers are disallowed from making external HTTP requests, and which services a container is allowed to run. Dynamic (also called ‘behavioral’) policies address issues such as containers connecting to undocumented ports, using more memory than normal, or exceeding runtime thresholds. Combining deterministic white and black lists with dynamic behavior detection offers the best of both worlds, enabling you to detect both simple policy violations and unexpected variations from the ordinary. We strongly recommend you include monitoring container activity in your security program. A couple container security vendors offer monitoring tools. Popular evaluation criteria include: Deployment Model: How does the product collect events? What events and API calls can it collect for inspection? Typically these products use one of two models for deployment: either an agent embedded in the host OS, or a fully privileged container-based monitor running in the Docker environment. How difficult are collectors to deploy? Do host-based agents require a host reboot to deploy or update? You need to assess what types of events can be captured. Policy Management: You need to evaluate how easy it is to build new policies or modify existing ones. You will want a standard set of security policies from the vendor to speed deployment, but you will also stand up and manage your own policies, so ease of management is key to long-term happiness. Behavioral Analysis: What, if any, behavioral analysis capabilities are available? How flexible are they – what types of data are available for use in policy decisions? Behavioral analysis starts with system monitoring to determine ‘normal’ behavior. The pre-built criteria for detecting aberrations are often limited to a few sets of indicators, such as user ID or IP address, but more advanced tools offer a dozen or more choices. The more you have available – such as system calls, network ports, resource usage, image ID, and inbound and outbound connectivity – the more flexible your controls can be. Activity Blocking: Does the vendor offer blocking of requests or activity? Blocking policy violations helps ensure containers behave as intended. Care is required because such policies can disrupt new functionality, causing friction between Development and Security, but blocking is invaluable for maintaining Security’s control over what containers can do. Platform Support: You need to verify your monitoring tool supports your OS platforms (CentOS, CoreOS, SUSE, Red Hat, Windows, etc.) and orchestration tool (Swarm, Kubernetes, Mesos, or ECS). Audit and Compliance What happened with the last build? Did we remove sshd from that container? Did we add the new security tests to Jenkins? Is the latest build in the repository? You may not know the answers off the top of your head, but you know where to get them: log files. Git, Jenkins, JFrog, Docker, and just about every development tool creates log files, which we use to figure out what happened – and all too often, what went wrong. There are people outside Development – namely Security and Compliance – with similar security-related questions about what is going on in the container environment, and whether security controls are functioning. Logs are how you get answers for these teams. Most of the earlier sections in this paper, covering areas such as build environments and runtime security, carry compliance requirements. These may be externally mandated like PCI-DSS or GLBA, or internal requirements from internal audit or security teams. Either way, auditors will want to see that security controls are in place and working. And no, they won’t just take your word for it – they will want audit reports for specific event types relevant to their audit. Similarly, if your company has a Security Operations Center, they will want all system and activity logs some time period to reconstruct events, and, investigate alerts, and/or determine whether a breach occurred. You really don’t want to get too deep into that stuff – just get them the data and let them worry about the details. CIS offers benchmarks and security checklists for container security, orchestration manager security, and most compliance initiatives. These are a good starting point for conducting basic security and compliance assessments of your container environment. In addition ‘vendors’ – both open source teams and cloud service providers – offer security deployment and architecture recommendations to help produce dependable environments. Finally, we see configuration checkers arriving in the

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.