Voice of the DBA

Tag: security

  • Hardware Hacking

    How safe are our chips?

    One of the reasons that we have so many gadgets at low costs, with a regular re-fresh and re-tool of the internals is that many of our computing chips and circuit boards are built overseas in factories that are optimized for low costs and rapid evolution to new technologies. That works fine for consumers, but it presents a problem for a government concerned with security.

    Since the fabrication plants are under the control of a foreign government, that means that the military and governments that want to use the same chips that consumers use must vet the designs, and then the end product. This piece talks about the problems with the supply chain that can come from foreign suppliers that might have incentives to allow hardware hacks into the designs at the request of their own governments.

    The world continues to grow closer economically, but we still have our own national patriotism and loyalty . We want our own countries to grow and do well, and our companies to grow inside of our own borders. As the stakes raise, will foreign supplies think about introducing backdoors or other hardware hacks into more of our chips? Imagine the problems we might have if our x64 chips contained a way for foreign companies to access our data?

    Criminals certainly would love these hardware hacks and as they get more and more sophisticated, I wouldn’t be surprised if this becomes an attack vector in the future. We might find in the future that we will not only have choices between Intel and AMD, but also choices between domestic produced and foreign produced chips.

    Steve Jones

     

    The Voice of the DBA Podcasts

  • The Woes of Cloud Computing

    Cloud computing: sunshine or rain?

    Many people have been skeptical about the move to cloud computing, especially in the database world. There are valid reasons to worry about security, legal issues, and more. I certainly think that using cloud services requires some planning and careful examination of the impact to your environment, but I also think that many companies will want to make the move, so it pays to learn more about cloud computing and be prepared with realistic, rational concerns from the database perspective.

    Anthony Skipper of ServiceMesh gave a presentation on some of the problems and lessons learned from moving to cloud computing. It was picked up in an Information Week piece that summarizes some of the areas that can cause problems for your company. The list of issues is a good one, and worth reading through.

    There are a couple of items in the list that I thought were very interesting for data professionals. The first was the fact that companies need to ensure that they implement policy from the beginning for how cloud services will be used. I think this will always be a point of contention between IT and the clients, and this isn’t an excuse to lock down clients or limit their options. Instead it ought to be a place where IT looks to be informed, help with guidance, and respond more quickly to client requests. IT cannot be the stumbling block in the cloud, or it will get left behind.

    The other thing? This quote: Have the ability to bring things back internally or to another provider at any point. That’s a great point. The cloud isn’t the ultimate answer, and you ought to have a backup plan, which should include the ability to move your services back to your own data center.

    Steve Jones

    The Voice of the DBA Podcasts

  • How Many Times Will This Happen?

    Laptops are being stolen with important data on them. Unencrypted.

    This editorial was originally published on Jun 6, 2006. Steve is traveling in the UK this week and we are reprinting a few pieces.

    Or is it a sign of the times and something that we’ll have in the news on a regular basis for the next few years? Another laptop theft with data, this time from Hotels.com. It was actually an Ernst & Young laptop, the firm that audits hotels.com, but still.

    This makes me feel silly for complaining about JD Edwards laptops and the required Pointsec encryption we had to put on every laptop. I didn’t like it at the time, but it wasn’t a horrible intrusion and these days I think a necessary one.

    With all of the hype on identity theft, data privacy, and portable computers, I cannot believe that every company that allows any data to go outside of their physical office, whether on a backup tape or a laptop, doesn’t require encryption or some type of protection. At least do something to protect it. Most thefts are random and the thief probably wasn’t looking for credit card data, so a simple password might protect the data in most cases.

    If governments want to do something about identity theft and privacy, pass that law. Force everyone to encrypt their data and us in IT to come up with good ways to protect it. I didn’t like encrypting backups with Litespeed, the only choice a few years ago, but it was worth it to protect backup tapes. Now with more choices at very reasonable prices, and MSDE/SQL Express able to use them, every database that contains individual data, and especially financial data, should have its backups encrypted.

    Steve Jones

  • The difference between REVOKE and DENY

    There was confusion recently with a poster that was moving permissions around and asked why I said they should revoke permissions and not deny them. I decided this was worth a post to explain.

    If I GRANT SELECT (or UPDATE/INSERT/DELETE) permissions to a user, then they can use those permissions to view data in a table. If I REVOKE the permissions, it’s the same as if the user never had them. They would need to be GRANTed permissions again to see the data.

    However, if I DENY them the ability to see data, then that’s different. They can’t see the data, but a subsequent GRANT will not allow them to see the data because the DENY will still be in effect.

    It’s a more permanent change, and should be used when you need to be sure that someone cannot see data, not when you are looking to remove permissions. To undo a GRANT, use REVOKE.