At Cisco we understand that the field of IT has grown considerably over the past few years, reaching the point where even professionals in the industry can have a hard time keeping up with everything that is happening in all areas. With groups like Anonymous and LulzSec taking down some pretty big names, it is clear that there is need for greater awareness of security and some of the issues that make security an interesting but ongoing challenge.
This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.
The National Strategy for Trusted Identities in Cyberspace (NSTIC) proposes a large ecosystem of identity providers, attribute providers, and relying parties that must establish trust with each other in various ways. NSTIC requires various types of trust within the identity ecosystem. These include:
- Users must trust that their Identity Provider will manage their credentials securely and in their best interest.
- Relying Parties must trust in the attributes provided by Attribute Providers.
- Relying Parties must trust Identity Providers to provide the requested strength of authentication and to manage credentials and attributes correctly.
The term “federated identity” is widely used to refer to identity systems that span multiple organizations, each of which maintains its own identity information. That arrangement is typically used between an enterprise and its business partners, such as contract manufacturers, channel partners, and consulting firms. Trust is established individually with each. A fully meshed federation of n participants would require n(n-1) such agreements, which does not scale well beyond small federations, especially considering that these agreements often take the form of contractual negotiation between each party.
Cisco has over the years developed a reputation for robust, dependable and well supported products. Perhaps a bit conservative, but solid, well built, reliable choices. Choices that are especially well suited to those who are building networks with security integrated into the very fabric of the network itself rather than bolted on afterwards in a best-effort, jugaad or MacGyvered way. One thing we have not been known for is being particularly cheap.
Things have changed. While we still deliver the very best support and our products are still robust, they have these attributes while also delivering stellar bang for the buck. Case in point, a recent comparison done by Miercom where the Cisco ASA 5585-X went up against a similarly spec’ed and priced Juniper SRX3600 and beat it in handily in performance and power consumption at a price that is either roughly equal or cheaper than the Juniper box.
Testing was done with both BreakingPoint (here’s a link of some earlier test results with the ASA on BreakingPoint that they released at RSA 2011 earlier this year) and Spirent. Both boxes performed well in general, with the ASA turning in 24.5 Gbps and the SRX hitting 22.0 Gbps with TCP EMIX traffic, as shown in Figure 1 (above) from the Miercom report.
However, when looking at Concurrent TCP Connections, the tables turned, revealing a pretty significant advantage for the ASA. As shown in Figure 2, below, the ASA provided 10.0 million concurrent TCP connections, compared to 2.39 million for the SRX.
On the green front it gets even more interesting. Cisco as a company is big into green, with our EnergyWise being one example. Many of our execs are also personally into going green with home solar installations and the like, but green doesn’t necessarily mean you have to give up performance. One example is the Tesla Roadster, a zero emissions electric vehicle that also sports a massive 295 ft lbs of torque at 0 rpm (!) and rockets to 60 mph (100km/h) in 3.7 seconds. I was recently checking one out at the Tesla store in Santana Row in San Jose and was surprised to see our own Tom Gillis with a big grin in some of their interactive displays. I think Tom fits in the little roadster better than I did
Getting back to ASAs and SRXs though, the Cisco green DNA shows through when you consider that at maximum load the Cisco used just 425 watts, while the Juniper consumed 1168 watts at idle, a significant difference, particularly when you factor in cooling as well.
As you think about the security of your company, employees, information and assets, what are the topics that are “top of mind” for you? What keeps you up at night?
Starting next month on the Cisco Security Blog, we will be sharing a series of “Top of Mind” blog posts from our security leaders. These experts from Cisco’s diverse security community offer a wealth of knowledge and experience on all aspects of security. They will share their top of mind concerns, considerations, approaches, and solutions as they focus on securing the Cisco enterprise. We believe the information they share will be important thought leadership, direction and guidance for you to consider applying in your own environments.
We welcome your input to keep this security dialogue interactive and relevant to you. In fact, we’d like to challenge you to use this forum to challenge us, by sharing your thoughts and concerns, and asking the hard questions that will lead us all to be more secure. If there is a specific topic you would like to hear about, let us know. We look forward to the discussion, so that together we can improve our collective security.
Other than semantics, what’s the difference between the two access control list configurations presented below? They both look much the same, in fact, but the key differentiation is one of context! Take a few minutes and read ahead…
ip access-list extended Access-Control
permit tcp host 192.168.100.1 10.0.0.0 0.0.0.255 eq 80
permit udp host 192.168.150.1 10.0.0.0 0.0.0.255 eq 69
deny tcp any 10.0.0.0 0.0.0.255 eq 23
deny ip any any
access-list 150 permit tcp host 192.168.100.1 10.0.0.0 0.0.0.255 eq 80
access-list 150 permit udp host 192.168.150.1 10.0.0.0 0.0.0.255 eq 69
access-list 150 deny tcp any 10.0.0.0 0.0.0.255 eq 23
access-list 150 deny ip any any
Understanding ACLs (access-control lists), or moreover, the difference between standard ACLs, extended ACLs, VLAN ACLs (VACLs), and access-control entries (ACEs) — the individual lines that comprise an ACL — is a challenge in and of itself, but now you read a Cisco Applied Mitigation Bulletin (AMB) and see the terms iACL and tACL: great, another acronym and concept to grasp? You bet!