October 26, 2008
Top Ten Security Requirements for Enterprise Applications
When developing an application for the enterprise, product managers have long known the “must have” features that customers
demand. Output to crystal reports? – check. Support for IIS?– check. MSI agent installer? check.
With the rise in focus on security there has emerged a set of security requirements that enterprise software vendors
must consider or else they run the risk of watching their sales pipeline come to a screeching halt. The following are ten requirements that I have come across while doing some proof of concepts:
Enterprise applications of today must be developed such that they can be split into three separate tiers of Web, App and Database. The reason is simple, that’s how
most enterprises are split today –at least three distinct security zones. If your application can’t fit nicely into that model, then there is a good chance it won’t pass security or compliance standards. For instance: you can’t have web access to an application in the database tier and you can’t have a database in the
Enterprise applications must integrate with the company’s user repository.
So, be prepared for the question: Do you integrate with LDAP? With that requirement out of the way, customers will inevitably
want to know that your integration does not require a sync. A sync with LDAP inevitably leaves you with another user store to manage.
Stick with a no sync LDAP connector. And don’t forget support for SSL over LDAP; a requirement that’s becoming more prevalent. Also, make sure LDAP support is
for both application users AND administration. One common mistake is applications will provide support for application user accounts but not administration of the application itself. Compliance and governance controls are the most strict when it comes to administration.
If you don’t have LDAP, Radius will do. Though not preferred and burdened with its own security risks, most organizations
will accept radius as an acceptable alternative to LDAP.
# 3: Integration with Siteminder
An extension of the previous requirement, centralized authentication and access is a must for any enterprise. In today’s web enabled world, that means web Access control. The market might look crowded but in reality, Siteminder(CA) reigns supreme. CoreID (Oracle), TIM/TAM (IBM), and Cleartrust (RSA) might be gaining ground but for now, their reach is mostly limited to marketing and shelfware.
Ideally, integration with Siteminder means certified connector. Lacking that, you can default to Radius, which Siteminder supports nicely. Having said that, be sure you have tested and created ad “Integration with Siteminder” guide.
#4: Audit Logs should output to Syslog / Syslog(NG)
The ability to generate audit logs has been a “must have” feature in enterprise applications for a while. The ability to forward those logs to a central log server has taken center stage as “must have” requirement
Compliance and regulatory requirements have become prescriptive in their definition of logging to include centralized logging servers and daily reviews. This translates to integration with the organization’s log management solution. Rather than try to pick the vendor of the day to integrate with, the ability to output to Syslog is probably the most cost effective way to ensure that you will meet your customer’s requirement. Syslog is a standard and that even the most closed log management solutions begrudgingly support.
#5: Support for NTP
What good is logging if the time stamps are not synced? Anyone who has tried to conduct an investigation using out of synced logged files will tell you that it’s a non starter
The push to centrally log every device (See requirement #4) has resulted in a dramatic comeback for one of the oldest protocols on the internet: NTP
Enterprise applications of today must have support for the network time protocol (NTP). While this support should be native, integration with the underlying server’s time is also acceptable. The software vendor should be prepared to discuss how they will integrate with the organization’s NTP infrastructure. For instance, Java Applications using Log4J will write logs based on the underlying server’s time. If the server is synced to the company’s NTP server, then the logs will be synced as well.
#6: Support for proxy authentication
Given the segmentation of networks today, proxy’s have become the norm in many enterprises, even at the application and web tiers. While most vendors readily
support proxy ports; one feature that I consistently forgotten is authentication support. The increasing importance of generating meaningful logs means that most enterprises today require individual accounts for even the most basic of tasks such as internet access. Couple this with policy based access control and you have an increasingly growing need for authentication to the proxy.
#7: Encryption on storage
Enterprise applications of today must have native support for file or database level encryption.
Encryption upon storage has become the standard prescriptive requirement for most compliance and regulatory standards. In addition encryption must be of an appropriate strength (at least 128bit) and standards based (non proprietary). Any data that is stored on disk and can be deemed sensitive (SSN, Credit Card #’s, Account information, Passwords, etc) should be encrypted.
#8: Encryption on transmission
Enterprise applications of today must natively support transmission encryption.
While this requirement is focused around sensitive data, software vendors will do well to plan to support encrypting ALL internetworking communications. The reality of it is that most enterprise require encrypted transmission even across vlans. In the very least, support should be in place for server to user communication, web administration, and web services (HTTPS over Soap).
#9: Key management and key control
Enterprise applications should have support for key control and key management. As encryption has gained traction, so has the need to properly control the key management process. Keys used in encryption should be unique to each enterprise deployment and the customer should be able to rotate them. “Black box” keys generic in the application’s .dll are starting to come under scrutiny by security professionals. In addition, keys should be split knowledge-d or dynamically created to promote secure storage.
Role based policies for administration
Enterprise applications should have role based policies for administration. Separation of duties has become a key control for many enterprises. Administration of enterprise applications have to take in account different users with different roles. In addition to read only groups, software developers should include support for security, admin, and auditor roles.
In conclusion, the framework for developing an enterprise application has always been a based meeting customer requirements for integration and interoperability with existing business processes. As governance and compliance has become a foundational IT process, security has become fundamental for integration.
this on Delicious