Before I delve into the meat of today’s post I want to say that the goal of this series is to aid IT security and database admins in protecting relational databases from DoS attacks. During the course of this research I have heard several rumors of database DoS but not found anyone willing to go on record or even provide details anonymously. Which is too bad – this type of information helps the community and helps reduce the number of companies affected. Another interesting note: we have been…
The point of sending the kids to sleepaway camp is that they experience things they normally wouldn’t. They expand their worldviews, meet new people, and do things they might not normally do when under the watchful (and at times draconian) eyes of their parents. As long as it’s legal and appropriate I’m cool.
This morning Cisco made its first decisive move in the network security space in years, acquiring Sourcefire for $2.7 billion. That represents a 30% premium over Sourcefire’s closing price yesterday. But much more importantly it is a clear signal that Cisco hasn’t given up on security and intends to compete as organizations rebuild their network security around the poorly named next generation application awareness technology.
We have discussed why continuous security monitoring is important, how we define CSM, and finally how you should be classifying your assets to figure out the most appropriate levels of monitoring. Now let’s dig into the problems you are trying to solve with CSM. At the highest level we generally see three discrete use cases:
From the Amazon Web Services security blog:
A best practice in this area is to use a bastion. A bastion is a special purpose server instance that is designed to be the primary access point from the Internet and acts as a proxy to your other EC2 instances.
It seems Universities are the latest targets for targeted attackers, looking for a preview of the next set of technologies to come out of the major research universities. But protecting these networks is a herculean task, given the open nature of university operations, which are driven by collaboration and sharing. It makes it tough to protect things when they are fundamentally open.
We don’t know much about last week’s Apple security incident, but a security researcher claims he is responsible, and was just doing research and reporting it to Apple.
As anyone reading this site knows, I have been spending a ton of time looking at practical approaches to cloud security. An area of particular interest is infrastructure encryption. The cloud is actually spurring a resurgence in interest in data encryption (well, that and the NSA, but I won’t go there).
From CNet (and my inbox, as a member of the developer program):
Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed. In the spirit of transparency, we want to inform you of the issue. We took the site…
As we mentioned in the last post, anti-malware tends to be the anchor in endpoint security control sets. Given the typical attacks that is justified, but too many organizations forget the importance of keeping devices up-to-date and configured securely. Even “advanced attackers” don’t like to burn 0-day attacks when they don’t need to. So leaving long-patched vulnerabilities exposed, or keeping unnecessary services active on endpoints, makes it easy for them to own your devices. The progression…