Security for developers – III

Article summary

This week we continue to explore common mistakes in the context of application security management.

If you have been following the article series, you must be disgusted with the mistakes committed! Unfortunately, there are more. As this list is really long (and still not complete), I will attempt to complete it in this article itself.

10 SA Password is hard-coded in the app!

This is probably the most glaring of mistakes I have seen till date. In a client–server app, I have seen the SA password hard-coded! Thus the EXE contains the password.

If you change the SA password, you have to change the pwd in the EXE, recompile it and redistribute it! Imaging how innovative and ignorant people can be.

11 Password is sent over the wire in unencrypted form – even in Web apps

All this occurs because developers do not understand how vulnerable their code can be. When you have custom username and password dialogs, the password can be detected by the most simple network sniffing software.

Please do not use this method. Rely on methods which do not send passwords over the wire. Or use network encryption protocol like HTTPS to protect the data.

12 Database Roles are not used

In the original list of mistakes I published in the earlier article, this title was incorrect. It was mentioned as “Database roles are used”. Actually it should have been as shown here.

Even if some applications use better logon security, within the database, there are further problems.

General security principle says that any user context should have minimal security rights or permissions. Just enough to manage the work to be done.

If you do a quick audit about what happens in reality, you will be shocked!

Most user contexts in databases are mapped either to SA or they somehow have maximum possible rights.

Why should a regular user, who requires select, insert, update, delete and SP execution rights, also be allowed to create and drop databases and tables? Does it make sense? It does not.

Please go back to your applications and check if the users have excessive permissions. If yes, revoke unnecessary permissions.

Within SQL Server you should use Server and Database Roles. This makes sure that the SQL Server application is in-charge of the security.

If you don’t know how to use them, please read the security section of SQL Server Books Online!

13 COM and MTS is not used

Now this is called Enterprise Services in .NET. However the concept remains the same. The idea is to route all database related activities through middle-tier objects! No direct execution of SQL commands or Stored Procedures.

Yes this would add one more layer. And things will become slower. That is a regular excuse for not understanding the significance of new technology.

In brief, the extra time overhead this has is more than eliminated by the benefits this offers. What are the benefits?

Read the topics MTS and Enterprise Services to understand them fully, but here’s a brief encapsulation of the benefits: Automated transaction management, role based security management, de-linking of logged on user context from internal database access context, connection and object pooling, object level events, distributed transactions, load balancing, automatic indirection and so on.

Too much to learn? Yes it is. But that is why we chose IT. Right?

14 Backup restore policies do not respect security aspects

Generally backup operators also have other administrator rights. Ideally backup operators should not be able to view data. This role is often played by low end outsourced providers. Nobody cares about exposing data to people who should not. That is why more than 50% of hacking and IT related damage arises from internal sources – not external hackers.

15 Permissions are given in an ad-hoc manner

If at all permissions are explicitly given, they are given in a very ad-hoc manner. Typically, admin people who do not understand anything about application development end up managing permissions.

Further, nobody understands the power of negative permissions. Negative permissions means DENY or REVOKE type of permissions.

Even if you have inherited Allow permission, a local DENY blocks it effectively. This is a very important concept in any security implementation and needs to be understood fully.

16 Application roles are not used

Apart from Server and Database roles, SQL Server also offers application specific roles. These roles rely on an application specific password, which is supplied programmatically. End users do not need to know this password. By using this feature, SQL Server ensures that the connection and user have rights only within the specified database. This reduces the attack surface effectively.

17 Multiple application have the same password

This is actually called Single Sign On. This is actually a good thing. Not a problem. But this is often a problem because of the way usernames and passwords are stored.

If the userid/pwd table is a custom table with easily breakable authentication code, having a single sign-on is a risk than a convenience.

If you are implementing single sign on, ensure that you use integrated windows security. Do not try to write your own code to handle security.

18 Physical security is always compromised

Have you not seen data centers or access control doors where smart card / biometric security is available, but the door is anyway kept open — for convenience?

That is the state of physical security. How do you know a developer has not sent a zip copy of a CSV file containing account balances from the live banking software using a simple USB key or a mail to some external account?

The more you think about it, the more pathetic it is.

The simple rule of security is – “Trust nobody” – including the people who designed the application.

Who should know this? The decision makers and business owners. Do you know any such person?

19 Administrator is the complete owner

Never logon as administrator. Ideally, all administrator access should be removed or at least disabled. This is for all products. Not just database or OS.

Always work in least privilege mode. Whether it is an anonymous user, authenticated user, database user, running service, batch process or interactive user.

20 Low end / outsourced / contract staff has access to data

This is a very important threat. Under the hype of outsourcing, you do not realise that more and more volatile and in-experienced people have access to sensitive data and infrastructure.

This needs to be regulated and monitored. Otherwise, we have many disasters waiting to happen – either due to intentional pilferage or due to sheer ignorance leading to system damage.

21 Nobody is particularly sensitive about security issues

Who should be? Everyone thinks it is the problem of IT. Within IT people think it should be managed by Admin guys. Admin guys thing the security policy should be written and evolved by external security consultants. This goes on and on. The final result is generally far from secure.

People wake up only if there is damage reported. Patch up for some time, and then again go back to dormancy.

Nobody understands that prevention is the only method of security. Not patch up.

22 Security against Internal attacks is almost non-existent

This has been covered in past. Due to lax internal controls, internal staff has easy and unmonitored access to IT infrastructure. This makes it easy for internal people to misuse information or facilities.

23 Automated patch management is not properly implemented

Patches are not applied to all the relevant places. Only the affected servers are patched. Others are not. Some people seriously believe that patches should be applied only to servers which are directly connected to Web!

24 Proactive monitoring of logs and counters is not done

All applications (sorry — all well written applications) provide adequate amount of logs, intrusion detection information, success and failure audit trails and so on. These logs become voluminous over time. Logs have no meaning unless they are analysed proactively to look for abnormalities and suspicious information.

How many of us have this policy set and implemented? Across how many servers? What happens if someone fails to analyse logs? Is there a mechanism to detect it?

25 Auditing is not enabled to the appropriate level

All enterprise level applications provide extensive audit trails. But often we have to explicitly enable these. For example, SQL Server 2000 offers C2 level audit trail. Most don’t even know how to enable it, leave alone using it and analysing it.

26 MBSA is not run periodically

The most simple and easy step everybody should take in managing security is to run MBSA. This is Microsoft Baseline Security Analyzer. This is a free downloadable tool from MS site.

This should be run on every computer in your organisation periodically. This checks if all standard security practices are implemented or not. If not, it gives a list. You are supposed to look at the problem areas and solve them. This part is manual!

27 Multiple applications run on a single machine

This is an obvious mistake. Firstly, it may lead to performance issues. Secondly, you are creating a single point of failure. If one app is hacked, there is a good chance that other applications will also be damaged. Depending upon the sensitivity and importance of applications to your business, you should consider separate servers just for security reasons (leaving aside the performance concerns).

28 There are too many database servers

This is not necessarily a problem by itself. But as you know we have a long list of mistakes by now. Each mistake leading to some vulnerability. If you have too many servers, all repeating the same mistakes, imagine how vulnerable your setup is. Therefore, having too many mismanaged servers is a problem. If your application demands it, of course you need multiple servers.

29 Appropriate Login accounts are not present on Log Shipping server

This is not a common problem. But it still is. Log shipping is a method of creating a warm standby server for SQL Server 2000. This should be used if you don’t mind the downtime of starting another server in case the live one goes down.

If this feature is being used, the accounts on the main server should be present on the secondary

30 Too many persons are effective ‘sa’

Another common problem is that too many people are at the level of SA or administrator equivalent. This makes things more vulnerable. Ideally these accounts should not be shared. If at all these need to be shared, it should be with minimum people.

If others are giving you admin password, you should think twice before accepting it. Why? Because the moment you are one of the administrators and something goes wrong, you are implicitly responsible! Whether you did the mistake or not does not matter. Think about it.

31 Stored procedure level security is almost missing

Ideally, if you are not using components, you should use stored procedures to manage data access. This improves performance and also increases the level of security.

Unfortunately, it is still common to use ad-hoc queries for performing data access from all sorts of applications.

Why don’t people ever improve?

32 Stored procedures are not encrypted

Ideally SPs should be encrypted. Why? If someone hacks into your database, at least they will not know the exact business logic. It is a simple command. Nobody knows it. Nobody does it.

33 Backups are not adequately protected

This has been mentioned in an earlier section. Further, backup tapes or CDs are not encrypted or kept in secure places. If they are, the usage and access is not documented.

I have known of people removing hard disks from official computers, taking them to data recovery experts, extracting data and then fitting hard disk back!

If you are now talking about a simple tape or CD containing MDF, LDF files, see how insecure it is.

34 Backups are often taken on insecure hard disks

Backups should be taken on removable media. This way, the media can be stored in a secure site away from the main site.

For convenience, many of us store backup on another computer next to the server. If there is an earthquake or fire, what is the use of that backup? We know that, but we still do it.

Why? Because we really don’t care!

35 ‘C2 Audit Mode’ is almost never enabled

This has been covered earlier in section 26.

36 Business owners are not even aware of the threats

All this is happening and is being tolerated because nobody really cares. No developer or Project Manager or Architect has lost his/her job or has had pay deducted because they wrote code which was not secure.

Incompetence is not just widespread, it is accepted and in most cases not even noticed.

The only way to come out of this and manage security proactively is to make sure the top management understands how vulnerable their system are.

Why top management? Because they have maximum to lose in case things go wrong. What will happen to IT professionals? Nothing much. What will happen to the largest stakeholder in the board? Much more. His life may be ruined with few well targeted damages to sensitive information. But do they seem to be aware and scared of this? No way. Like everyone else, they delegate security management to consultants, admin guys, developers and outsourced vendors (thinking they have saved costs!).

Bottom-line, top management is the weakest point in security management. Everything else is the effect of it.

Summary

This list is by no means complete. This is just an introduction to how vulnerable most applications are. You may feel bad or offended with this statement. In that case, just go through your applications, use this list as a baseline check to and find out if these mistakes are valid in your case.

If yes, first thank God and the hackers in the world (who are more powerful in this case) that you are still safe. Now, correct the problems immediately and be more proactive in future.

If no, congratulations! But remember, this list is not complete!