Many Cisco customers with an interest in product security are aware of our security advisories and other publications issued by our Product Security Incident Response Team (PSIRT). That awareness is probably more acute than usual following the recent Cisco IOS Software Security Advisory Bundled Publication on September 25. But many may not be aware of the reasoning behind why, when, and how Cisco airs its “dirty laundry.”
Our primary reason for disclosing vulnerabilities is to ensure customers are able to accurately assess, mitigate, and remediate the risk our vulnerabilities may pose to the security of their networks.
In order to deliver on that promise, Cisco has has made some fundamental and formative decisions that we’ve carried forward since our first security advisory in June 1995.
Read More »
Tags: advisories, Cisco Security, incident response, IOS, ncsam-2013, psirt, vulnerability
In the last week alone, two investigations I have been involved with have come to a standstill due to the lack of attribution logging data. One investigation was halted due to the lack of user activity logging within an application, the other from a lack of network-based activity logs. Convincing the asset owners of the need for logging after-the-fact was easy. But ideally, this type of data would be collected before it’s needed for an investigation. Understanding what data is critical to log, engaging with the asset owners to ensure logs contain meaningful information, and preparing log data for consumption by a security monitoring organization are ultimately responsibilities of the security monitoring organization itself. Perhaps in a utopian world, asset owners will engage an InfoSec team proactively and say, “I have a new host/app. To where should I send my log data which contains attributable information for user behavior which will be useful to you for security monitoring?” In lieu of that idealism, what follows is a primer on logs as they relate to attribution in the context of security event monitoring. Read More »
Tags: CSIRT, csirt-playbook, incident response, logging, logs, NCSAM, ncsam-2013, security, SIEM
Your network, servers, and a horde of laptops have been hacked. You might suspect it, or you might think it’s not possible, but it’s happened already. What’s your next move?
The dilemma of the “next move” is that you can only discover an attack either as it’s happening, or after it’s already happened. In most cases, it’s the latter, which justifies the need for a computer security incident response team (CSIRT). Brandon Enright, Matthew Valites, myself, and many other security professionals constitute Cisco’s CSIRT. We’re the team that gets called in to investigate security incidents for Cisco. We help architect monitoring solutions and strategies and enable the rest of our team to discover security incidents as soon as possible. We are responsible for monitoring the network and responding to incidents discovered both internally by our systems or reported to us externally via email@example.com.
Securing and monitoring a giant multinational high-speed network can be quite a challenge. Volume and diversity, not complexity, are our primary enemies when it comes to incident response. We index close to a terabyte of log data per day across Cisco, along with processing billions of NetFlow records, millions of intrusion detection alarms, and millions of host security log records. This doesn’t even include the much larger data store of authentication and authorization data for thousands of people. Naturally, like all large corporations, dedicated attackers, hacking collectives, hacktivists, and typical malware/crimeware affect Cisco. Combine these threats with internally sourced security issues, and we’ve got plenty of work cut out for us.
Read More »
Tags: Cisco Security, cisco sio, CSIRT, csirt-playbook, incident response, infosec, logging, logs, playbook, security, SIEM
After delivering several presentations at Cisco Live and Cisco Connect this year, I received a few questions regarding DNS Response Policy Zones (RPZ) and how can they be used to block DNS resolution to known malicious hosts and sites. I decided to write this short post to explain what it is and provide several pointers.
DNS RPZ is a technology developed by ISC available since Bind version 9.8. Network administrators can use DNS RPZ to essentially stop malware-infected hosts from reaching their command and control (C&C) servers by blocking DNS resolution to known malicious hosts and sites. This effectively turns a recursive DNS server into a DNS firewall. In fact, many people refer to DNS RPZ as the “DNS Firewall.” Various ISPs are testing and implementing this to provide additional protection to their customers.
Note: DNS RPZ will block DNS resolution, machines connecting to the C&C via IP address will not be blocked.
The following figure provides an overview of how DNS RPZ works.
Read More »
Tags: cisco sio, cyber crime, cyber security, dns, dns rpz, incident response, malicious dns requests, malware, Response Policy Zones, RPZ
I see and hear a variety of acronyms being used on a daily basis. I recently heard one tossed around with good humor that makes a point: TMA or Too Many Acronyms. Every once in a while, when I think I’ve embedded the definition and use of an acronym into my long-term memory (anything beyond an extended weekend), it seems as if either a new acronym was spawned, or it has been overloaded with a different meaning. My goal in this blog post is offer both a refresher on some topical acronyms that appear to be quite commonly circulated in security technology circles and media outlets. It is challenging to be a subject matter expert in every aspect of cyber security. Whether you are reading an article, joining a conversation or preparing for a presentation or certification in the realm of cyber security, you may not be completely perplexed by these acronyms when you come across them and become more familiar with them. For situational purposes, I organized the acronyms into categories where I have seen them used frequently and included related links for each of them.
AAA: Authentication, Authorization, and Accounting. This is a set of actions that enable you to control over who is allowed access to the network, what services they are allowed to use once they have access, and track the services and network resources being accessed.
ACL/tACL/iACL/VACL/PACL: Access Control List. ACLs are used to filter traffic based upon a set of rules that you define. For ACLs listed with a prefix (for example, t=transit, i=infrastructure, V=VLAN (Virtual Local Area Network), P=Port)), these ACLs have special purposes to address a particular need within the network.
FW/NGFW/FWSM/ASASM: Firewall/Next Generation Firewall/Firewall Service Module/Adaptive Security Appliance Services Module. These products provide a set of security features designed to govern the communications via the network. Cisco provides firewall features as a dedicated appliance or hardware module that can be added to a network device such as a router.
IPS: Intrusion Prevention System. Typically, this is a network appliance that is used to examine network traffic for the purposes of protecting against targeted attacks, malware, and application and operating system vulnerabilities. In order to ensure the effectiveness of a Cisco IPS device, it should be maintained using Cisco’s IPS subscription service.
DNSSEC: Domain Name System (DNS) Security Extensions. That’s right, we have an acronym within an acronym. These are the specifications for security characteristics that make it possible to verify the authenticity of information stored in DNS. This validation makes it possible to provide assurances to resolvers that when they request a particular piece of information from the DNS, that they receive the correct information published by the authoritative source. Read More »
Tags: byod security, Cisco Security, cybersecurity, HIPAA Compliance, incident response, MDM, PCI Compliance, pci-dss, security, vulnerability