DNS is like the town gossip of the network infrastructure. Computers and apps ask DNS questions and you can ask DNS who has been asking to resolve malware domains. When internal trusted systems are using DNS to resolve the names of known malware sites, this can be an Indicator of Compromise and a warning to clean the potentially infected systems and block traffic to the domain.
Blacklisting the known malware domains using local RPZs, firewalls, Cisco IronPort Web Security Appliance (WSA), or Cloud Web Security (CWS) is a great way to add an extra level of security in organizations. But what if you are just getting started in the process of cleaning systems and just need some situational awareness? Or, how can you manually check to see if these devices are working as expected? How can you determine independently of security devices, and at any point in time, that client systems are not reaching out to malicious domains? You can use dig but this post focuses on a Python example. Let’s first take a look at some DNS mechanics.
Cryptography is critical to secure, trustworthy communications. Recent questions within the tech industry have created entirely new discussions about the cryptography underpinning our communications infrastructure. While some in the media have focused on the algorithm chosen for Deterministic Random Bit Generation (DRBG), we’ve seen many more look to have a broader crypto conversation. With this backdrop, I’d like to take the opportunity to talk about how we select algorithms (not just the DRBGs) for our products.
Before we go further, I’ll go ahead and get it out there: we don’t use the DUAL_EC_DRBG in our products. While it is true that some of the libraries in our products can support the DUAL_EC_DRBG, it is not invoked in our products. For our developers, the DRBG selection is driven by an internal standard and delivered to those developers from an internal team of crypto experts through a standard crypto library. The DRBG algorithm choice cannot be changed by the customer. Our Product Security Incident Response Team (PSIRT) confirmed this in a Security Response published on October 16.
Now when I’m talking about safekeeping a mobile device, I’m not saying don’t use your Kindle by the pool or let your toddler play on the iPad while eating ice cream. These are dangerous things to be doing with a gadget, but today I want to focus more on the data within that device, rather than the device itself.
No matter what you do, your device may be stolen. It only takes a moment of inattention for someone to swipe your phone or tablet. Before that unfortunate event occurs, there are several things that you can do to mitigate the damage that occurs from the loss of a mobile device. Read More »
Now that we’re in the midst of October 2013′s Cyber Security Awareness Month, it’s a good time to think about the connections between security awareness and trust. This discussion centers on three questions:
How do we trust our computers and devices?
How do we trust our vendors?
How do we trust the infrastructure?
We ask these questions mindful that information technology does not stand still and is probably accelerating. Forward progress, however, is unsustainable if we can’t trust the technologies we use. I don’t foresee any scenario where technology progress will come to a halt, but there are many ways it can fly off the rails if we’re not careful. This may sound dire, but I remain an optimist by nature and believe we can confidently move ahead if we take the time to think about security and trust and act on our conclusions. Cyber Security Awareness Month is a good opportunity to think about this, and I have more to say in the video blog post below:
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.