Why You Shouldn’t Skip the Infrastructure/Security Architecture Review

It’s not usual for development projects to undergo an architecture review, but too many times these reviews consist only of developers. There are no server or network folks, much less any DBAs or security personnel. When I’ve brought this up to some of my developer friends, they wonder what the issue is. After all, developers have a good grasp of how things work, right?

If you’re an infrastructure type, you’re probably chuckling right now (or shaking your head sadly). If you’re a developer, let me ask you a very basic question, “Do you think the admins who support you understand everything about the code you write?” The obvious answer is, “No,” they don’t. They are very smart people but you’ve spent years learning to code, working through design patterns, finding and solving bugs, and a whole lot more about writing code that infrastructure folks don’t even think about. 

Infrastructure folks also spend years specializing in what they know. A lot of what we know don’t even enter into the realm of the developer. Most developers just don’t encounter the problems and issues we do because we solve them before they do. For instance, a recent install comes to mind where the installation was having an issue because of a hardened configuration with respect to the NICs. 

If you just thought, “What do you mean, hardened NIC configuration?” you just proved my point. If you do know what I mean but you don’t deal with that sort of thing regularly, you’ve also proved my point. If you do think about those things regularly but are quite aware that most developers don’t, you probably see my point. Infrastructure folks have specialized knowledge to bring to an architecture discussion that is not in the wheelhouse of most developers. This knowledge, if the infrastructure people are absent, is also absent. 

Infrastructure folks aren’t looking to throw roadblocks up on projects out of malevolence. Okay, MOST infrastructure folks aren’t looking to do that. What we are looking to do is doing our best to ensure that systems going in or being updated are as secure as possible and perform as well as we can make them. We want to minimize risk for the organization. We want to help the organization make the most out of every IT investment. Sometimes that means we challenge back. We see an issue or an area for improvement. Of course we are going to bring it up. 

The later in the project where we get a look at what’s going in, the harder and more costly it will be to the organization to try and make things better. If it’s a showstopper, there may not be time to avoid everything coming to a screeching halt. That’s why it’s important to get the infrastructure folks involved early and keep them involved throughout the whole project. It’s harder, yes, but it’s also what is best for the organization.

More on that Cyberwar

As a follow-up to my post on being at war, cyberwar:

State Department Hacked

If the experts are correct, this trend is only going to continue. Reading the article and others on the same situation, they all note that the unclassified email had been hacked, but not classified. That’s a bit of good news, but it’s still not all that great. There’s a lot of useful information in unclassified email, especially for a department like the State Department.

 

SQL Server Security Benchmarks

If you’re not familiar with the Center for Internet Security, here’s the organization’s mission statement:

The Mission of the Center for Internet Security is to enhance the security readiness and response of public private sector entities, with a commitment to excellence through collaboration.

CIS produces consensus-based, best practice secure configuration benchmarks and security automation content, and serves as the key cyber security resource for state, local, territorial and trial governments, including chief security officers, homeland security advisors and fusion centers.  CIS provides products and resources that help partners achieve security goals through expert guidance and cost-effective solutions.

That consensus-based part means it’s mostly community-sourced. That means if you work on a product with a security benchmark, you can contribute. I bring this up because there are security benchmarks for SQL Server available for download and we are always looking for knowledgeable folks to contribute their expertise. This link is to the released version of the benchmark for the relevant SQL Server versions.

Not only are the finalized release versions of the benchmarks available, but we also are actively working on the benchmarks all the time. As a result, the next version of each benchmark is typically available for comments and proposed changes as a draft. The more knowledgeable folks contribute, the better we can make these benchmarks, which hopefully results in more secured SQL Servers around the world.

Also, once a product version has been out long enough, we start a benchmark for it, too. That means we’ve begun the security benchmark for SQL Server 2014. We’d love contributions from the community to make this a solid benchmark with its 1.0 release. If you have the time and experience working with SQL Server 2014 security, please take a look. The current draft is a copy of the 2012 one, so there are definitely changes to be made. Thanks!

 

Slides and Code for SSIG Talk

Thank you for those who made it out to the SQL Server Innovators Guild last night in Greenville, SC. I hope you enjoyed the talk and that it’ll create conversations about how we better secure the ETL pipeline. With attacks against data becoming more and more prevalent, I only see this area growing in concern, especially as we understand that attackers will get through the perimeter or are already there (like the life change issues we talked about).

 

ZIP file: ETL_Pipeline_Security_Slides_Code.zip (585 KB)

Speaking on ETL Security

I will be giving a presentation on ETL (Extract, Transform, Load) security at two user groups in the coming weeks.

Securing the ETL Pipeline

We’re going to look at typical ETL (Extract, Transform, Load) pipelines and consider the weak points an attacker might go after. Our goal in this isn’t to cause FUD (Fear, Uncertainty, and Doubt), but to discuss risks at each point, options for protecting the vulnerability, and what we’ve seen typically done (if anything). While this talk primarily focuses on Microsoft SQL Server, especially the database engine and SSIS, many of the points covered will be applicable to any solution set.

If you’re in or near the Midlands or Upstate of SC, I’d love for you to come out so we can meet and discuss this topic, professional development, and SQL Server in general:

August 5, 2014 – SQL Server Innovators Guild – Greenville, SC

August 14, 2014 – Midlands PASS Chapter – Columbia, SC

What is an “operational” DBA?

On Facebook last night, I posted the following:

An operational DBA isn’t just a manager of a traditional RDBMS, transactional system. An operational DBA manages the data platform, whatever it is, when it hits production. Their goals are not traditionally the same as someone focused on development. They are looking to keep the system secure, performing well, and ensure it is recoverable in case of failure/disaster. This could be over a traditional system, a no-SQL solution, a warehousing solution built around star/snowflake schemas, or anything that has to do with data storage, management, and retrieval. If you think an operational DBA is a manager of just a transactional system, please update your definition. Operations has changed greatly in the last decade to keep pace with development and business.

The reason I posted this is because I saw some indications that there is a misunderstanding of what an operational DBA is nowadays. Not surprisingly, this misunderstanding came from folks who aren’t in an operational role. Here’s the gist of what an operational DBA is typically concerned with:

  • Production security
  • Production performance / reliability
  • Production recovery

I’m not ranking those in order of importance. The order of those three items depends on the environment. I’ve been in environments where security was more important performance / reliability or recovery (military). I’ve also been in environments where performance /reliability was king.

Note that I didn’t include a particular type of platform. That’s on purpose. I also didn’t indicate whether or not production was on premise or hosted. That’s also on purpose. If you’re still thinking that an operational DBA is only concerned with the care and feeding of an on-premise transactional SQL Server, Oracle, DB2, MySQL/MariaDB, etc. platform, it’s time to update your thinking. An operational DBA takes over when a system transfers from Dev/QA/UAT to production, when it becomes operational (hence the name). Platform, type, where it’s hosted, and those types of details are irrelevant if the system is about data management and it just rolled to production. While there are some operational DBAs who solely focus on transactional systems, that’s not true of all operational DBAs. And that’s not what we operational types mean when we say, “operations.”

“A good DBA is a lazy DBA”

I’m borrowing from Andy Leonard (blog | twitter) who says all the time, “Good engineers are lazy.”

If you’re thinking, “Why would I want (to be) a lazy DBA?” let me explain. There’s a lot to be said for hard work. However, have you ever seen someone who is always busy but seems to get very little done? Hard work, in and of itself, isn’t the goal. The goal is to get things done. This is where laziness comes in.

If I have to repeat a task, I should look at automating it. I don’t want to have to repeat those steps each time. I want to be lazy. For instance, as an operational person, there are a lot of things I need to review within my production environment on a periodic basis to ensure my systems are running as they should. Case in point: ensuring the SQL Server drives don’t run out of free space. This is something that I should monitor regularly (daily).  There are different ways I could handle this:

  • I could log on to each server and check each drive.
  • I could use a tool like TreeSize to hit the drives one by one.
  • I could automate the checks which results in a report in my inbox.

I prefer the last option. If I’m smart, I’ll even schedule it to run so it’s ready for me when I get in each morning. But why stop there? I could not only automate gathering the data, but also automate some of the analysis. Let’s say I set thresholds and the automation bubbles up anything crossing a threshold to the top of my report, meaning the most important data gets seen first. I don’t want to just be lazy, I want to be very lazy. By being this lazy and automating, I free up the one resource I can never get more of: time.

What can you automate? Anything and everything you can successfully automate frees up time for you to spend tackling other things. The more your organization sees and understands that you do, the more valuable you are. If you are in IT but don’t happen to be a DBA, this is still a solid approach. Let me generalize and say being a lazy IT pro is being a good IT pro.

 

Previous Older Entries Next Newer Entries