Bruce Schneier, the security technologist and author famously said, “Complexity is the worst enemy of security.”
We have been working with some customers who agree strongly with this sentiment because they have been struggling with increasing complexity in their access control lists and firewall rules.
Typical indicators of operational complexity have been:
- The time that it can take for some organizations to update rules to allow access to new services or applications, because of the risks of misconfiguring rules. For some customers, the number of hours defining and actually configuring changes may be an issue, for other customers the biggest issue may be the number of days that it takes to work through change control processes before a new application is actually in production.
- The number of people who may need to be involved in rule changes when there are high volumes of trouble tickets requiring rule changes.
Virtualization tends to result in larger numbers of application servers being defined in rule sets. In addition, we are seeing that some customers need to define new policies to distinguish between BYOD and managed endpoint users as part of their data center access controls. At the same time, in many environments, it is rare to find that rules are efficiently removed because administrators find it difficult to ascertain that those rules are no longer required. The end result is that rule tables only increase in size.
TrustSec is a solution developed within Cisco, which describes assets and resources on the network by higher-layer business identifiers, which we refer to as Security Group Tags, instead of describing assets by IP addresses and subnets.
Those of us working at Cisco on our TrustSec technology have been looking at two particular aspects of how this technology may help remove complexity in security operations:
- Using logical groupings to define protected assets like servers in order to simplify rule bases and make them more manageable.
- Dynamically updating membership of these logical groups to avoid rule changes being required when assets move or new virtual workloads are provisioned.
While originally conceived as a method to provide role-based access control for user devices or accelerate access control list processing, the technology is proving of much broader benefit, not least for simplifying firewall rule sets.
For example, this is how we can use Security Group Tags to define access policies in our ASA platforms:
Being able to describe systems by their business role, instead of where they are on the network, means that servers as well as users can move around the network but still retain the same privileges.
In typical rule sets that we have analyzed, we discovered that we can reduce the size of rule tables by as much as 60-80% when we use Security Group Tags to describe protected assets. That alone may be helpful, but further simplification benefits arise from looking at the actual policies themselves and how platforms such as the Cisco Adaptive Security Appliance (ASA) can use these security groups.
- Security policies defined for the ASA can now be written in terms of application server roles, categories of BYOD endpoints, or the business roles of users, becoming much easier to understand.
- When virtual workloads are added to an existing security group, we may not need any rule changes to be applied to get access to those workloads.
- When workloads move, even if IP addresses change, the ASA will not require a rule change if the role is being determined by a Security Group Tag.
- Logs can now indicate the roles of the systems involved, to simplify analysis and troubleshooting.
- Decisions to apply additional security services like IPS or Cloud Web Security services to flows, can now be made based upon the security group tags.
- Rules written using group tags instead of IP addresses also may have much less scope for misconfiguration.
In terms of incident response and analysis, customers are also finding value in the ability to administratively change the Security Group Tag assigned to specific hosts, in order to invoke additional security analysis or processing in the network.
By removing the need for complex rule changes to be made when server moves take place or network changes occur, we are hoping that customers can save time and effort and more effectively meet their compliance goals.
For more information please refer to www.cisco.com/go/trustsec.
Follow @CiscoSecurity on Twitter for more security news and announcements.
Tags: ASA, byod, security, Security Group tags, TrustSec
About two years ago, I went into a customer workshop on private cloud. As we were introducing ourselves around the table, the CIO turned to me with a pained expression and said, “Bob I have a different problem. My CFO and CEO just asked me if I knew how many of our users were accessing cloud services. They asked me if I knew how much we were spending or if there were any risks.” He said, “I don’t know the answers, and I don’t have a plan.”
In the months that followed, I would have countless other conversations with CIOs, that highlighted an emerging challenge—shadow IT. Shadow IT turns up when business groups implement a public cloud service without the knowledge of IT. In working with our customers, we have found that there are typically 5-10 times more cloud services being used than are known by IT.
The conversations I had with customers highlighted that shadow IT was creating several challenges—from monitoring cloud costs to managing service providers. One of the significant challenges with shadow IT is risk to the business. Specifically, we have seen five categories of risk arise:
#1 Data Security Risks
Company information being shared externally due to a cloud service breach is among our customers’ worst nightmares. Cloud vendors work hard to protect customers’ data. However, it falls to the business to know where their information lives and to protect it.
A security officer of a global non-profit organization recently shared with me that his organization wanted to use cloud services to help connect with donors and manage operations. However, they weren’t set up to govern providers and have no idea how donor information was being shared with cloud vendors. Many of our customers tell us they don’t have strong processes to manage cloud vendors, can’t track how their information is being shared, and often don’t know how vendors are keeping their information safe.
#2 Brand Risks
Brand risk goes hand-in-hand with a potential data security breach. If company information is stolen, or shared inappropriately, the consequences to an organization’s brand is immeasurable. Not only can a breach lead to negative press and customer backlash, but can also result in financial damages.
#3 Compliance Risks
Globally, organizations face evolving and expanding regulations that require them to retain information, maintain privacy, give people the ‘right to be forgotten,’ and more. As cloud services are used across all business functions, companies face the risk of falling out of compliance. Our customers tell us that violations are becoming more frequent as those responsible for enforcing compliance become less aware of what services are being used. Also, employees often don’t understand when using a cloud service can trigger compliance issues.
#4 Business Continuity Risks
Businesses need to ensure that cloud vendors they are using have strong business fundamentals or risk losing valuable corporate information if a vendor goes out of business or is purchased. Last year, a cloud storage provider Nirvanix went out of business and gave customers less than one month to move their data or risk losing it forever. These types of abrupt changes can lead to significant challenges in maintaining business continuity.
#5 Financial Risks
Recently, we helped a global equipment manufacturer discover that their employees were using over 630 cloud services, 90 percent of which were unknown to IT. These unknown services cost them nearly a million dollars annually. Costs are spiraling as businesses unknowingly purchase duplicate cloud services and lose their power to negotiate bulk contracts.
Identifying Cloud Risks With Cisco Cloud Consumption Services
The first step to managing the risks of shadow IT is to identify where you might face exposure. To help customers with this challenge, Cisco has introduced a new service designed to identify the business risks and costs resulting from shadow IT.
With Cisco Cloud Consumption Services, customers can know which public cloud services are being used in their business, become more agile, reduce risks, and optimize public cloud costs.
Using collection tools in the network, we help customers find out what cloud services are being used by employees across their entire organization. Our cloud experts then help customers identify and manage cloud security risks and compliance issues. Using a proprietary database of cloud vendors, we help companies identify the risk profile of services they are using and provide recommendations for managing these risks with stronger cloud service provider governance. The service also helps customers determine what they are really spending on cloud and find ways to save money.
Additionally, Cisco Cloud Consumption Services helps companies develop new processes for managing cloud vendors, from onboarding to termination. We help customers to proactively manage risks and deliver new services faster by establishing stronger cloud service management practices.
You can learn more about how we can help you understand your cloud usage and identify risks to your business at www.cisco.com/go/cloudconsumption
Many leaders that I speak with feel like they do not have a shadow IT problem, citing that their security protocols were set up to protect them. Think this is you? Think again! Recently we worked with a provincial government and discovered that they had over 650 public cloud services being used by their organization, despite blocking 90 percent of internet traffic. Simply put, if your employees have access to the internet, you have a shadow IT challenge.
I’d be interested to hear from you as to whether you feel you have challenges with shadow IT and what the risks could be. I look forward to your comments!
Tags: Cisco Cloud Consumption Services, Cisco Live! 2014, risk, security, Shadow IT
On January 16, 2014, Proofpoint discussed a spam attack conducted via “smart devices which have been compromised.” Among the devices cited by Proofpoint as participating in the “Thingbot” were routers, set-top boxes, game consoles, and purportedly, even one refrigerator. Of course, news about a refrigerator sending spam generates considerable media attention, as it should, since an attack by the Internet of Things (IoT) would represent a high-water mark in the evolution of (in)security on the Internet. However, soon after Proofpoint’s post, Symantec published a response indicating that IoT devices were not responsible for the spam attack in question, and the machines behind the spam attack were all really just infected Windows boxes. So why is determining the identify of the devices used in this spam attack so difficult?
Read More »
Tags: IoT, spam, TRAC
Why do so many organizations maintain essentially open, “flat” networks, leaving thousands of users and devices with network-layer reach to their “crown jewels”? Especially in light of what we know with data breaches, theft, and loss? One possibility may be that some organizations simply grew too quickly, and the tools in the tool chest to implement network segmentation were onerous. Other tools or point products were deployed, making it easy to say “we have Identity and Access Management Systems” for that.
But this argument falls flat in the face of a massively-increased attack surface. How did organizations become so vulnerable? Easy – the combination of enterprise mobility trends, the exponential proliferation of devices, and the dramatic increase in workloads made possible by virtualized data centers. Combine that with advanced threats – the notion that with just one social engineering attack, an adversary can quickly move across systems until he finds valuable information – and organizations quickly start to realize that network segmentation and restricting network reach are more than just “nice-to-have,” but rather, an imperative.
Limiting who and what have network-layer reach to sensitive resources to those that truly have a need to know makes a lot of sense. The trouble has been that traditional methods of implementing network segmentation and network access control are generally cumbersome and entirely dependent on how the network is architected. Need to change or maintain the policy? You may be in for major network changes and massive resource hours – whether to redesign VLANs and IP-based ACLs, or simply to rewrite thousands upon thousands of firewall rules (in many of locations). Ouch.
Fortunately, there’s a readily available technology to apply secure access policy independent of network topology. If you can (1) classify the users and devices that access resources, (2) classify the resources themselves, and (3) specify the access permissions between these classifications, then Cisco TrustSec can enforce that policy within the network – it’s that simple.
Take a look at the example above. Here, we show a simple policy that specifies how different classes of users can access various resources in the data center. Changing this policy by changing a permission or adding a new class of users or resources is really straightforward and easy-to-understand. There’s no need to redesign VLANs, carve up the IP address space and (re) subnet the network, and/or re-write IP-based ACLs or firewall rules.
To learn how TrustSec can help protect your organization’s crown jewels by limiting the reach of who and what has access to sensitive resources, check out www.cisco.com/go/trustsec.
Follow @CiscoSecurity on Twitter for more security news and announcements, and, if you’re in Milan, Italy, during the last week of January, come visit us at Cisco Live! Milan! We’d love to see you!
Tags: security, TrustSec
With encouragement from customers, Cisco has submitted the TrustSec protocol that we use to exchange role and context information between network devices to the IETF. Chris Young, Senior Vice President of Cisco Security, shared the news during his keynote address at Cisco Live! Milan.
The Source-group tag eXchange Protocol (SXP) has been submitted to the IETF as an informational draft, in order to open up TrustSec capabilities to other vendors. In our experience, defining access controls and segmentation functions using logical policy groups, instead of IP addresses and subnets, removes operational complexity for customers. When we authorize a user device or a server as a member of a policy group, SXP allows us to propagate that information to devices that reuse that intelligent classification and apply security policies based upon it.
We have published SXP to enable interoperability with TrustSec functions in widely deployed Cisco products, so customers can not only simplify security policy management in diverse networking environments, but also use the classification for other purposes beyond security. For that reason, we have used the term source-group, instead of the more familiar security group designation, in the draft.
For more information please refer to http://tools.ietf.org/html/draft-smith-kandula-sxp-00
If you’re at Cisco Live! Milan this week, please do come to the Cisco campus, we will be pleased to talk more about TrustSec and show examples of TrustSec in action.
Tags: cisco live, TrustSec