As we pass the halfway point of National Cyber Security Awareness Month (NCSAM), I wanted to call attention to some of our colleagues over on the Cisco Government Blog. Patrick Finn and Peter Romness have been busy this month espousing the need for security and we thought it would be beneficial to expose our readers to their thoughts on security that have been published on the Cisco Government Blog space. Read More »
Many organizations make the error of thinking that basic defensive software is sufficient to protect critical data and infrastructure. When in reality, in order for government and enterprise organizations to keep their data protected from increasingly advanced cyber threats, comprehensive defensive security approaches are critical. And even with advanced, comprehensive solutions, there are still risks.
No organization is ever going to be able to protect 100 percent of its assets 100 percent of the time, which is why I work on the 95/5 principle. No matter how many security solutions are deployed, if attackers are determined enough, they will find a hole. Humans make mistakes and without fail, attackers will take advantage of them.
With comprehensive security approaches, we can regularly block at least 95 percent of threats—but there is always going to be a margin of error—the other 5 percent. A proactive, continuous approach can help ensure the vast majority of offensive moves are rejected.
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.
Dude, where’s my IP?
I love to check in on social networks like Foursquare and Google+. Most of the time, there’s no point to it, but it’s fun to see what friends and colleagues are up to or discover new local haunts. Despite the fun and games, location is much more important to the network than it appears. My physical location may have little or everything to do with my network location and there’s no reason for them to match exactly, but there are significant reasons to be more accurate.
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.