Category: Cyber Security

The benefits of application containers have been shared across a variety of forums and to a diverse audience. The ability to have more application instances without a corresponding increase in hardware is probably the primary benefit that is used to persuade enterprises to adopt application containers. But if that is the primary benefit, meeting the objectives of the rapid deployment associated with DevOps is a close second.

Application containers allow developers to easily modify and test because applications are siloed in their own containers. So, the benefits are appealing from a cost savings perspective as well as support of DevOps deployment. Is there a downside, though?

Perhaps it is not a downside as much as a consideration, but as organizations adopt application containerization, some cultural shifts are necessary. These shifts relate to operational processes that organizations may already have in place; however, containerization requires doing those familiar processes differently. Because the change is for an existing process rather than the implementation of something new, the change is more cultural than operational. For example, in a traditional application environment, generally, there is a structured process for code review, which the time to deployment accommodates. As deployment time is shortened (as in a scenario involving DevOps and application containers), organizations may be challenged in how they perform formal, structured code reviews. So, a cultural shift to identify (and accept) solutions that provide assurance around secure coding in the containerized environment despite the rapid speed of deployment may be required.

Another area where a cultural shift may be required relates to access. Unless an organization develops a strategy around administrator access, it is possible for administrators to have access to multiple hosts, containers and images rather than the specific hosts, containers and images to which the administrator needs access to perform job responsibilities. Ensuring that a least privilege strategy is implemented would addresses this. Also, beyond internal expectations, several compliance initiatives, such as the Health Insurance Portability Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS) and the General Data Protection Regulation (GDPR) rely on strong access controls.

Lastly, an organization’s approach to authentication may require a cultural shift. In administering workloads, orchestrators potentially place workloads that have varying levels of sensitivity on the same host. To address this, an orchestrator may have its own authentication directory. This directory, however, may be separate from other non-orchestrator authentication directories in use. As a result, the orchestrator’s authentication directory may have different authentication practices. A concerted effort to ensure alignment of authentication practices for all directories (orchestrator-related or not) may be necessary. These efforts may include, but are not limited to, restricting administrator authentication access to specific repositories rather than multiple repositories.

The benefits of adopting application containers are appealing. More application instances may be possible without incurring the cost of additional hardware and deployment time may be reduced. Effective adoption, however, depends on how organizations can modify existing protocols to accommodate the containerized environment. Code review, access and authentication are examples of areas for which organizations routinely have controls but where a cultural shift is necessary. Once these shifts have been made, the benefits or application containers can be fully realized.

Robin Lyons, Technical Research Manager, ISACA

[ISACA Now Blog]

The Software-Defined Perimeter (SDP) Working Group was founded five years ago, with a mission to promote and evangelize a new, more secure architecture for managing user access to applications. Since the initial publication of the SDP Specification, we’ve witnessed growing adoption and awareness throughout the industry. As practitioners, vendors, evangelists, and guides, we (as the SDP working group) have learned a great deal about SDP in practice, and wanted to capture and share that knowledge.

This was the driver for us to create the forthcoming Software-Defined Perimeter Architecture Guide. We’ve decided to publish a preview blog series here to obtain feedback on this work-in-progress artifact, and to spark conversation about SDP architectures and deployments. Ultimately, we intend the final published Architecture Guide—scheduled for publication in Q4 2018—to encourage broader (and more successful) adoption of SDP architectures.

Please join the conversation in the SDP working group here—we’re open to feedback, questions, or even just good restaurant recommendations. Thanks for reading this, and we look forward to engaging with you.

In this first blog posting, we’re going to walk through the SDP Architecture Guide outline and provide color commentary. Keep in mind that this document is still a work-in-progress, so the content and structure may well change prior to publication. Let’s dive in:

• Introduction
  • Why We Wrote This Document
  • Target Audience
  • Goals
  • SDP Scenarios

In the introduction, we provide the motivation for the document, articulate who our target audience is, and explain our goals. Then, we enumerate SDP scenarios (AKA use cases), briefly explaining each one, and exploring the benefits that SDP provides in that scenario.

• SDP, Zero Trust, and Google’s BeyondCorp

In addition to SDP, there is a lot of noise and activity in today’s marketplace around the Zero-Trust philosophy, and to some degree about Google’s internal BeyondCorp security initiative. In this section, we attempt to make sense of this and explain the similarities and differences between them.

• SDP Overview
  • Core SDP Concepts
  • SDP Architecture
  • SDP Deployment Models
    • Client-to-Gateway Model
    • Client-to-Server
    • Server-to-Server Model
    • Client-to-Server-to-Client
    • Client-to-Gateway-to-Client
    • An Alternative Architecture: The Cloud-Routed Model

This section presents the foundational elements of SDP, including its core underlying concepts. We also dive into the SDP architecture and discuss each of the SDP deployment models.

• • Single-Packet Authorization
    • SPA Benefits

Single-Packet Authorization (SPA) is one of most important parts of SDP. By compensating for the fundamentally open (and insecure) nature of TCP/IP, SPA enables secure and reliable deployment of SDP Controllers and Gateways onto insecure and public networks. In this section, we analyze the SPA protocol, suggest some improvements, and expand upon its benefits to SDP.

• • SDP Policy Model
    • SDP Policy Overview
    • Policy Components

SDP, as a specification, is silent on a policy model. In this section, we introduce the elements that an SDP policy model should have and the corresponding capabilities that an SDP platform should be able to express. We conclude this section with a few example policies.

• SDP in the Enterprise
  • Architecture Considerations
  • Security and IT Technologies
    • SIEM
    • Firewalls
    • Intrusion Detection/Prevention Systems
    • Virtual Private Networks
    • Next-Generation Firewalls
    • Identity and Access Management
    • VPNs
    • NAC
    • SDN
    • IDS / IPS
    • EMM / MDM
    • Web Application Firewalls
    • Cloud Access Security Brokers

This section introduces a simplified (but prototypical) enterprise model, exploring how each of the Security and IT technologies shown above are impacted by the deployment of SDP.

• SDP Business Benefits

We conclude with the business benefits that SDP can deliver. This section, which will be constructed in a tabular format, will provide an overview of these benefits. We look forward to providing more detailed, quantified benefits and case studies in a future document.

Thanks for reading through the outline. In our next blog post in this series we’ll talk through the SDP Core Concepts table.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

[Cloud Security Alliance Blog]

How do you prove you are you? In the physical world, we have birth certificates and driver’s licenses to prove we are who we say we are. Yet this question becomes more difficult when you are trying prove yourself to a computer system. Thankfully, Multi-Factor Authentication (MFA) can help in a variety of ways.

MFA is a method of authorizing a user’s claimed identity and granting that user access to a system. MFA is achieved after a user has provided two or more factors to an authenticating mechanism, such as something the user knows, has, or is. MFA factors can be derived from any of the three.

A common example of a factor would be your username and password. Both are a form of something you know. Stemming from MFA is Two-Factor Authentication (2FA). This is an MFA protocol that requires a user to present a unique factor from two separate mechanisms, as often comes into play with an ATM card. You are only able to use your ATM card if 1) you have the card, and 2) you know the PIN associated with the card.

Finally, we have Two-Step Authentication (2SA). Two types of 2SA are a disconnected token (such as hard tokens and Keyfobs), and a soft token, which is an application that will generate a unique number combination. While both serve the same function, each has its own advantages and disadvantages. For instance, hard tokens cannot be duplicated. However hard tokens are costly to acquire and have to be physically handed to each and every user, creating an administrative burden. Soft tokens, on the other hand, can be widely disseminated, ensuring the likelihood that it is an authorized user requesting access to the system. Yet soft tokens are more susceptible to outside attacks than a hard token.

Whether you use a soft or hard token, you are still limiting the application to either a physical device that a user must always retain and not lose, or an app on a person’s phone. Both tokens can be lost, eaten by the family dog, broken, or otherwise rendered useless. What then? You can use something you have, something you know, and more importantly, something you are. Biometrics, the use of physical characteristics, such as an eye scan, fingerprint readers, and facial recognition, can potentially eliminate passwords, thus removing the password recovery requirement, a key vulnerability of MFA/2FA/2SA. Biometrics are instant, require no keys, and are unique to each individual.

While biometrics seem promising, there are some potential challenges. If a user relies on facial recognition software and gets a tattoo or a facial injury, will that prevent him or her from using the feature? Some users may have damaged fingerprints, rendering that option useless. Further, the use of biometrics implies that every user has a smartphone or tool capable of reading and comparing the data to a table for reference and approval.

Be it hard or soft token, or biometrics, each MFA option has its benefits and its costs. Which one you or your company choose will be based on the size of your company, the scope of users requiring a token, and what level of risk your company is willing to accept.

Cory Missimore, Assistant Manager, Information Security Compliance, Bloomberg BNA

[ISACA Now Blog]

Security departments have their hands full. The first half of my career was government-centric, and we always seemed to be the “no” team, eliminating most initiatives before they started. The risks were often found to outweigh the benefits, and unless there was a very strong executive sponsor, say the CEO or Sector President, the ideas would be shelved.

More recently, as a response to the security “no” team, IT staff started several “Shadow IT” projects. People began using cloud computing systems and pay-as-you-go strategies on a corporate credit card to quickly develop and roll-out projects before anyone in security could get a word in.

These “beg forgiveness” aspects hamstrung security on several projects, especially if a data leakage incident occurred or breach was in progress. What’s more, we weren’t unique in seeing shadow projects. These projects increasingly become the norm as IT staff looking to move initiatives forward come up against cybersecurity professionals hell-bent on maintaining security and, who know that in the event of a breach, heads could easily roll. Most likely theirs.

Tired of being seen as the “no” team? Here are three ideas that could reshape the value of security to your company as a whole:

Demonstrate Trust

Trust messages needs to come from outside of the department, even if it’s ghostwritten or created internally. Be it the CTO, CFO or CEO, there needs to be a bit of understanding that risk comes in many forms, and the Security Department takes all of those into account before approving or denying projects.

Many compliance frameworks have an HR or training domain, and some security departments successfully use this for mandatory training for topics like phishing. When a non-infosec colleague clicks on a fake attack, the trust point may be reiterated with a reminder of example fines and the costs. Breach notifications or PCI violations aren’t cheap after all.

Show Security as a Business Enabler

Share a couple of department wins, where the security team found involvement early in the process and added value to the program deployed. Look for examples like oAuth or Single Sign On (SSO) simplifying a portal’s usage or a project where business continuity planning or encryption helped pass an acceptance audit.

Demonstrating that security builds team success and is no longer the “no” department pays dividends.

Provide Educational Incentives

Lastly, extend the educational aspect beyond testing for ignorance. See if your organization offers reimbursement or even bonuses for security certifications, and stand-up internal lunch-and-learn or video conference preparation sessions. If your organization doesn’t provide an across-the-board financial incentive, maybe fund a raffle for five of the folks who pass the test to receive a spot bonus.

Hopefully, you’ll find these as an opportunity to impress upon the rest of the corporation the importance of the CISO’s office. There’s a long history of “no;” without efforts on the infosec staff’s part, that image will linger well past its truth.

Jon-Michael C. Brook, Principal at Guide Holdings, LLC, has 20 years of experience in information security with such organizations as Raytheon, Northrop Grumman, Booz Allen Hamilton, Optiv Security and Symantec. He is co-chair of CSA’s Top Threats Working Group and the Cloud Broker Working Group, and contributor to several additional working groups. Brook is a Certified Certificate of Cloud Security Knowledge+ (CCSK+) trainer and Cloud Controls Matrix (CCM) reviewer and trainer.

[Cloud Security Alliance Blog]