Development

Don’t Be Seduced Just Yet

I had a co-worker ask me yesterday what my opinion on “cloud computing” is, and whether it should be something they could recommend to clients. He had seen announcements about cloud computing from Microsoft

According to a 2008 paper published by IEEE Internet Computing “Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, table computers, notebooks, wall computers, handhelds, sensors, monitors, etc.” Another criteria is that it be massively scalable.

“Cloud Computing” is almost the same as “SaaS” (software as a service), the difference being, according to Gartner, scalability.

What I found the most interesting was the statement from Microsoft: Windows Azure provides developers with on-demand compute and storage to host, scale, and manage Web applications on the Internet through Microsoft® data centers. (the bold emphasis is mine.)

So, a business runs all it’s core applications and stores all it’s data on Microsoft’s servers. Windows is actually developing Azure as a separate platform from Windows server and desktop apps. It’s all accessible anywhere from the Internet. I guess Microsoft has decided to get into the Data Center business arena along with IBM and HP.

This is probably a silly question, but what do you have if there is no Internet access? There seems to be a massive assumption that all business functions can be run over the Internet.

The ONE statement about security on their opening page was: Security supported by flexible Code Access Security policies and The built-in management services give monitoring and tracing capabilities.

That’s IT???? I admit it is a page pitched to software development, but shouldn’t secure software development and the security of data centers be in there anywhere? The FAQ offered up nothing on that topic, as well. It did, however, offer up pricing.

So, I’m going to be terribly cynical and say that this might be Microsoft’s approach to controlling the rampant software piracy of their products going on all over the world. How about promoting it as a “more secure platform?”

Other than being a marketing ploy, “cloud computing” sounds like “thin client” writ large. There may be some significant financial savings, if you have the right kind of business to use this platform. AND you want to turn your data security over to Microsoft.

Microsoft’s only mention of “risk” - Windows Azure provides you, the developer, with a scalable platform and a rich development environment that allows you to focus on the business logic of your application without worrying about operational constraints or lock-in,” didn’t get me to “wow.” How often has security lagged far behind software development and what is Microsoft doing to change that? From this announcement, nothing.

Auditing MS SQL - Roles, and Why They Matter

SQL “Server” runs on top of MS Windows, and it has groups inside of it that are not seen on the Windows server or even the Windows Domain. That’s why we have to check and make sure that inappropriate users don’t have complete access to everything inside the database. Not everyone should be looking at those payroll files!

So, to confuse us a little more, instead of calling them groups (like Users, Administrators, Power Users, etc) SQL calls them “roles.” There are roles based on SQL as a whole (the SQL “Server”) and roles based on individual databases. Kind of like Domain Admins vs Local Admins.

SQL Server roles are equal to Domain Admins inside SQL Server. They give rights to many different core functions of SQL, and the sysadmins role has rights to everything inside SQL. By default, sa is here, but you should look very carefully at any other user in this group. DBAs like to give themselves a “backdoor” into the server this way, but that should be removed. Best practices recommend always having the DBA use their Domain ID for insertion into this role. This way you can log and monitor their access, and when they leave the company and their ID is disabled, they won’t be able to access the SQL databases. It also let’s them know that you are watching, and people tend to behave better that way.

I have found that software developers LOVE to put their names in this group, and not their Domain IDs, either. If it’s a production database, they have no business having anything other than SELECT rights anywhere. Kick ‘em out!

Here’s the SQL Server roles default permissions:

Fixed Server Roles
Sysadmin – can perform any activity (and Builtin\Administrators are part of this group by default)
Serveradmin – can set SQL-server config options and shut down SQL Server.
Securityadmin – manage logins and CREATE DATABASE permissions, read error logs and change passwords (within SQL, not Windows)
Setupadmin - manages linked servers and startup procedures
Processadmin – can manage processes running in SQL server
Dbcreator- can create alter and drop databases
Diskadmin - can manage disk files
Bulkadmin - can execute BULK INSERT statements

How do you find out who is in these roles? Use the results of a stored procedure: sp_helpsrvrolemember with the results taken from the Master database.

For individual databases, there are database roles. People in these roles can be all powerful, but only within that individual database, not all of SQL. How do you know how many databases are inside one SQL Server installation? Again, a stored procedure: sp_helpdb

You’d be surprised how DBAs like to create their own little mini databases (on production boxes!) just to “do things.” They may be great “things,” but those databases need to go somewhere else.

In order to see the members of all the database roles, run another stored procedure: sp_helprolemember run from each production database in SQL Server. It’s a little tedious, but you will get the information you need.

I commonly monitor the membership in the db_owner role (equivalent to a local server Administrator). By default, the dbo, or db_owner is the only one in this role. If the DBAs are already sysadmins, they don’t need to be in this role, unless you want to be very granular in your controls (NOT a bad idea). Developers shouldn’t be in this role, or just as bad, the application ID of an application accessing data.

This is where a lot of software development falls off the security bandwagon. If the application ID is db_owner, it means that the ID has access to everything in that database. If I can acquire the application ID’s password, (and some of them don’t have one) I can get into all the data. I wouldn’t use the application, just connect directly via ODBC or even Excel.

It’s easier to write applications using the application ID as db_owner, but unless you are using middleware to vet everyone’s login via the Windows Domain, you take the risk of losing all that confidential data out the back door.

If you can acquire this information on a quarterly basis, you will go a long way towards having an easy audit and a better night’s sleep!

Making Software Developers Clean Up Their Act

In the course of many audits and pentests, I can’t tell you how many times I have found flaws and openings based on bad development practices. It’s downright painful. And yet software keeps coming out with the same problems. I know WHY this is happening, but I can’t stop it. YOU can.

Have you ever been in the position of having a software vendor say: “We’re not going to test that patch yet, you’ll have to wait for the next software release from us. If you patch it, we won’t support it.”

Or finding a security flaw in the application, reporting it to the vendor, and having them say they will charge your company to fix it as a “feature request.”

Or examining roles and rights in the database, and finding out everyone is sysadmin. Or better yet, the developer hardcoded his ID into the application.

I bet you have, and you know I have. Once the software is installed and in production, they have you over a barrel and they know it. Time to build a better barrel.

Time after time, I’ve found software applications that don’t secure the application user inside the database (giving that user rights to EVERYTHING). Why? Because it’s easier to code. You don’t have to spend time finding out what broke and fixing it when you lock user rights down. Some applications hardcode usernames and passwords right into the software so that it can never be changed (unless, of course, you pay for an upgrade). Even worse, I’ve seen it when the ID is hardcoded with a blank password. Why? It’s fast, cheap and easy.

How do YOU change it? Two ways:

First, raise management awareness so that you are at the table with the software salespeople to ask some hard questions. Is security part of their SDLC (Software Development LifeCycle)? Management can often be “wowed” by a product without ever looking under the hood. Ask how their product is secured, especially since it will probably be holding important data. Don’t be wowed by application level controls - get some hard answers on how the data is accessed.

Second, be there at contract time. This is the most important. Make sure it is written into the contract that they will fix all security flaws found in their product within 30 days. Make sure that they are responsible for testing OS patches quickly and reporting to you if it is OK to patch. Pick a timeline you can live with. After all, you’re paying them for a service.

If not, you’ll have to live with buggy code and I’ll have to audit it. We’re in this together.