Voice of the DBA

Tag: security

  • Project Zero for Better Security

    Google started Project Zero to study zero-day vulnerabilities in systems. They want to improve security and safety, at least from a software and hardware standpoint. Its mission is to make it more difficult to find and exploit issues in software. They published an update recently that showed vendors patching their software quicker, at least according to data from the last few years.

    The metrics show a change in patching from an average of 80 days a few years ago to 52 days in 2021. There were also patches that missed the 90-day deadline, though only one missed the 90-day time and also a 14-day grace period. They are also trying to help with the understanding of how well vendors are adapting to new challenges. I hope this pressures and inspires smaller vendors and even individual organizations to take security more seriously.

    I think that security is becoming *slightly* more important to vendors, especially as competition grows in any particular space. Vendors aren’t necessarily looking to spend time and energy where they don’t see a problem impacting revenue, but they do worry about customers abandoning their software, and a security issue is one reason for customers to look elsewhere. In the 2020s, there are plenty of customers that would consider changing software over security issues that don’t get fixed.

    I saw another note that showed more and more hackers are exploiting zero-day vulnerabilities. Even if you think you have strong security, who knows when someone will misconfigure a firewall and expose your system. It’s worth staying up to date, at least within the last patch for your critical systems. I certainly consider a database a critical system, and I’d include helper databases like Redis and Elasticsearch as critical systems.

    It’s easy to delay patching when nothing seems to be broken. However, patches are like oil changes. When the system lets you know that maintenance is overdue, it’s usually a catastrophic event.

    I like the disclosure and openness of groups like Project Zero and hope they start to pressure more software developers (and project managers) to promote secure coding along with quick patches for vulnerabilities.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Advanced Incident Response

    Early in my career, I worked at a few smaller companies where a problem with the computer systems meant I went into the office and stayed until things were working. As I went to a few larger companies, I wasn’t alone when a system went down, but the process was mostly the same. We figured out what was wrong and found a way to fix or replace things, occasionally with help from a vendor. Those were the (not necessarily) good days before our internal networks were connected to a public Internet.

    Companies developed formal incident response plans to deal with various issues, whether these were problems we caused ourselves or failures of an application. I had the fortune, or misfortune, to be involved in more than a few issues and learned a great deal in how to solve problems as well as how to manage the impact to a large number of employees.

    As email and Internet use grew, so did the attacks with viruses and other sorts of malware. Antivirus software helped a great deal, but these days ransomware seems to be a common problem that isn’t as preventable as I would have hoped. Quite a few friends have dealt with ransomware issues, most of which have not been widely reported in the news.

    I saw an article about a few things that you might want to consider adding to your incident response plan. While some of these items might be unique to the ransomware threat, the thing that struck me was that there is a need to react quickly, in real-time, in response to any detection of an issue. I can only assume this means that there needs to be some advanced monitoring of nodes to detect issues, and I’m not sure how many organizations would adopt this, but in today’s world where we want systems available 24/7, perhaps they will.

    Being on call is a part of working in many IT departments. Having a response plan, even the general outline of one, helps to coordinate resources and ensure that we use people effectively. Tools are important, especially in today’s complex world, and it is important that one of those tools is a simple backup, preferably air-gapped from your main systems. If you don’t have these things in place, you might suggest someone start assembling them. These days it seems it’s not if you will get attacked, but when.

    Lastly, I don’t often see this addressed in plans, but make sure you have spelled out some guidelines on rotating staff and getting rest. Far too many companies want “all hands on deck” and forget that normal business still needs to occur. Any incident could last longer than a day, and you want to ensure that some of your staff is fresh and ready to take over from those that do need rest. Don’t be afraid to send some people home, or better yet, don’t call them in the first place.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Would You Want to be on the Red Team?

    In the world of cybersecurity, a red team is a team of hackers that try to infiltrate a company, but at the request of the company. The idea is they look for vulnerabilities and issues and find them before criminal hackers do. They are the opposite of the blue team, who is trying to stop the red team and create defensive measures that prevent the red team from accessing data.

    Many large companies use red teams. Microsoft maintains a red team (and a blue team) that are constantly competing to break into their systems and defend them (depending on which side you are thinking about). I’m sure Amazon, Google, and other large companies do the same thing. It’s an interesting idea, though I bet this is a lot of repetitive work where you constantly repeat similar attacks with slight variations. There certainly is some creativity and research as well, and some acting if you social engineer situations, but it’s not the type of work I would want to do. I doubt it’s as exciting as Hollywood movies portray hacking.

    An organization could assemble a red team from external resources and use them to evaluate the security of your software, your infrastructure,  or even your people. There’s an article this week on getting started with a red team. Since companies are seeing more and more attacks against their systems, I would expect more to be proactive and either assemble or hire someone to test them. In fact, I bet there will be lots of cybersecurity people setting up their own companies to help here.

    Many of us might feel we are careful with security, and that we check for issues. I’m sure we do some of that, and many of us know how to secure things well. However, it’s easy to make a change and make a mistake. It’s easy to forget to include a group, or include the wrong group, in a security ACL. It’s easy to forget to check a setting or leave access open while we test and forget to go back and secure it properly.

    Attackers think differently. We can learn to do this, but it might be helpful to have someone else doing the attacking and then giving us a report on what to fix.

    Steve Jones

  • The Level of Security These Days

    Passwords aren’t going anywhere. While I would have thought there would be more advances by this time, and there are, the basic password is still required in many places, especially for resetting an account. Even those MFA places where I can click a notification or enter a code, I still sometimes need a password.

    That’s fine, and I think MFA is a good solution, but it doesn’t alleviate the need to have a strong password. Troy Hunt has written about this topic because we as a collective do a poor job of building passwords. Especially with regards to length. Some of that is poor app (and database) design where we unnecessarily limit password length. However, some of the issues are our fault, as we continue as a group to use poor habits and practices.

    There are many guidelines to use with passwords, one of which is the length. The length you should use keeps increasing because hardware power keeps growing. Because of new attacks and techniques, we ought to review what we think is strong on a periodic basis. My password manager defaulted to 8 characters when I started using it over 20 years ago. Since then I’ve increased that to 12, and now 15. I ask for mixed upper case, lower, and numbers, along with symbols. These are so random that every time I need to give one to my wife to enter in, she’s annoyed with the length and mix of keys that need to be pressed.

    I haven’t seen the brute force table from Hive Systems before, but I like the visual. It helps you determine how strong your password is with modern hardware. This is a similar graphic to the one I used in an encryption talk years ago, where it showed how much it would cost to rent compute power on AWS to brute force crack various algorithms. In case you were wondering, about 5 years ago you could crack a 512bit key on AWS for less than US$75.

    I like the graphic, and it shows that my 15 character passwords should be safe for years. This Friday, I’m wondering if you’re comfortable with your password lengths? Are they crack-able in less than a year? Take a look at the graphic and let us know.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.