Voice of the DBA

Tag: security

  • Securing the Things

    I would venture to guess that a lot of the data that will be produced in the next few years will come from various “things” that are implemented by companies, users, and governments. We tend to refer to the Internet of Things (IoT) as those computing devices that are small, specialized, and connected computing device that sends data elsewhere. Sensors, special purpose devices, and more make of the IoT spectrum, including many industrial and manufacturing hardware.

    Computers grew by leaps and bounds from approximately 250 worldwide in 1955 to one million in 1980 and 30 million by 1986. In 2015, the world saw 238 million computers sold worldwide. If we add smartphones, we had around 120 million sold in 2007 and 1.4 billion sold in 2015. Tablets add to this, but really, the large market is going to be IoT devices. 15 billion connected in 2015 with an estimate of 75 billion by 2025. I would wager that is going to be a low prediction.

    One of the major concerns with these devices is security, and with good reason. There have been hacks against many of these devices, and few have been designed or sold with security in mind. Quite a few devices assume a strong network perimeter inside of an organization, but history has shown us that these barriers aren’t always secure. What might be more disconcerting is that many of the hacks originate inside of the network boundary, whether from insiders or compromised devices. There’s a nice write up on the need for security with IoT. Microsoft recently proposed that we regulate privacy and security for the IoT devices.

    Many of these devices will generate data that we will use as data professionals. In fact, I expect a tremendous amount of data to be generated. If devices are hacked, we may end up with lots of suspect data. Even devices are secure, they may fail or have intermittent errors. How to we detect errant data and remove it from our data sets? How can we be sure anomalies aren’t just problems or failures in the device (or network)? These will be challenges for us moving forward.

    I don’t know that I think specific regulation is required, but I’d like to see some sort of framework devised. I think encryption should be required, as well as guidelines for the security of connections and data management. Perhaps a list of valid technologies could be used, growing and changing over time, including removing older items that might be outdated. For example, DES shouldn’t be allowed in any new deployments, and it really should be removed from old ones, though with some grace period. That means a regular investment in software development and upgrades that evolves our systems over time. Especially with regard to data security.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Software Has Bugs

    Every once in awhile I have someone I meet complaining about software quality, usually with regards to some piece of Microsoft software. I’ll invariably hear how there shouldn’t be bugs in SQL Server or Windows, and Microsoft isn’t testing their software. This person will claim that they write software with no bugs. I can’t remotely believe this is true, aside from small, somewhat trivial applications. All software has bugs, but there’s no way to disprove anyone’s assertions unless you can get to their software and examine it.

    I do think that some people think their software is more bulletproof than it really is, perhaps because no one really does test the limits of their work. It’s easy to assume that there aren’t problems when no one has ever probed deeply in the different ways the code might execute. After all, this is one of the reasons that developers turn in code that they think works, but in which others find bugs. They haven’t explored enough different inputs against the software. This is also why I think unit testing needs to be constant and evolutionary, growing and changing as you find new issues and bugs in your code.

    Recently a vulnerability was found in the Samba software, and apparently it has existed for seven years. This means lots of software was vulnerable, and everyone should be patching as soon as possible. I don’t know how many people have port 445 open to the Internet, or even open locally, but plenty of people might now know about the issue, so patching makes sense. Scans of the Internet have turned up hundreds of thousands of devices, some of which are running versions that can’t be patched.

    This isn’t meant to complain about Samba, but point out that this is code that is open source, lots of people have looked at and developed against, and I would guess no shortage of security people have checked this for potential vulnerabilities. And still a bug slips through.

    Security isn’t hopeless, but it’s also hard. Software development, with few boundaries limiting the choices developers can make, allows new interactions among the building blocks of code that have never been seen before. Building code is much, much more complicated than any physical structure because we don’t have any of the inherent limits of the physical environment. This means that we will, and do, struggle to test all of our software.

    I don’t think we’ll ever eliminate all bugs, but we can vastly improve quality (as many companies have), by moving to a more DevOps development style where we seek to constantly improve quality as a part of software development. We also have more and more developers also seeking to improve their skills, learning new and better patterns throughout their careers, and hopefully, building better software.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The Poor State of Secure Coding

    Security is becoming a bigger issue all the time. More companies are getting hacked and losing control of data. It seems every week there’s a new disclosure from some firm. Recently OneLogin had a breach, which is very disturbing as they provide a single sign on solution for customers. This year we’ve learned about E-Sports, XBOX, Playstation, IHG, Arby’s, River City Media, Verifone, Dun and Bradstreet, and more.  At this point, there’s no reason for any large organization to wonder if they’ll get hacked. They should be preparingfor when they get hacked.

    The state of coding is poor, with far too few developers understanding how to write secure code. Even trying to learn how to code securely is hard. Too many examples given show poor coding practices. If you search for secure coding practices, you’ll get information, but none of the sample applications, none of the common information that most people would use to write code, is returned. This is especially true of data access, where far too many examples use dynamic strings.

    Even if we had great developers, there are still issues. A look at a survey from O’Reilly and SIG shows that there are still plenty of companies that are interested in security, but don’t perform reviews or use tools. Certainly many organizations don’t invest in security tools or resources heavily, and many companies don’t want to spend extra time worrying about security when there are features to build and deploy.

    My wish is that large organizations would engage in constant pen testing and review of their systems, looking for vulnerabilities, and patching them. I would hope that insurance companies would start to deny claims when a patch for any software has been available for six months or longer. That might help reduce the number of issues from older libraries not being upgraded.

    I would also expect that any vendor selling software engage in some security review for their products. In fact, I’d hope that once a company sells a certain number of units, this would be required. I’m still amazed that this isn’t a requirement for purchase from more customers, but since most vendors don’t bother, perhaps avoiding purchases of un-reviewed software isn’t feasible. Maybe it’s just as well; even if we did have some sort of review, how many of us would understand what that means? How many of you really understand what PCI or HIPAA compliance means? How well has that helped us? I guess things could be a lot worse than they are today.

    Security is going to be an issue for a long time. All I can do is try to improve my own skills and ask you to do the same. Learn to code securely and try to improve the software you work on. It might only make a small difference, and you might never know if it helps, but I bet you’ll feel better about your own work.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.3MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Consider the Downside

    Technologists are often seen as cynical and disappointed by how poorly much code is written or maybe because an application architecture isn’t well designed. I hear no shortage of complaints over other people’s code, one of the reasons I think we have so many new projects started on Github (or other pubilc repos). Everyone thinks they can build better software than others.

    However, we are often quite optimistic when we write our own code. We throw together quick apps or scripts that solve a problem, expecting the best conditions. In general, we don’t think widely about the possible issues with our code. We build and test for the happy path.

    I thought about this as I saw this post on twitter. It shows a number of Trello boards that contain passwords. To be fair, as I researched this, most of these items are private boards, though seeing names and passwords in a Google search is worrisome. I suspect most of these boards are places where less than trustworthy individuals are storing data, but I did see no shortage of public Trello boards for various software development teams. No passwords were shown, but plenty of notes, and I didn’t spend a lot of time digging through the various cards, something I suspect a hacker would do.

    I think many cloud services are very useful and they help us work in new ways. The thing we should all keep in mind is that the search engines are always probing data, even if hackers aren’t. Perhaps there isn’t a concerted effort by anyone to look for our particular set of data, but you never know. Someone may stumble upon our data and if it’s publicly visible, that’s an issue. Even server names, IPs, and more can provide information that we’d rather not disclose.

    If for no other reason, consider that employment has changed in the world. More and more of us change jobs often. Today’s co-worker might be tomorrow’s disgruntled ex-employee that discloses information to anyone, or worse, to specific hackers that might make use of it. I’m not sure how much data from our companies is valuable in a general sense to a large group of hackers, but I know there are plenty of technical vandals that would use the information to cause disruption, because they can.

    Whenever you look to setup some new process, especially with secure data, please don’t treat this lightly. Expect that someone will find a way to cause issues. And if you use any service that is connected to the public Internet, I’d be extremely careful of the data that you store there. You might be surprised how much of it is visible in search engines.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn