Security is the most important aspect of the infrastructure. Every single change needs to be designed against vulnerabilities not only related to performance and business process errors, but also to security. Threat Modeling is the most overlooked, yet most critical part of application design.

It is always possible to design an application without security in mind and then build security into the infrastructure, but almost always too late. Businesses and people cannot afford to get two passes at the security implementation. It has to be done once. It has to be done right.

• Some common practices to keep in mind:
• Ensure that the application uses encrypted connection strings to the database
• Ensure that sensitive data fields in the database are encrypted.
  • Oracle VPD, or Application Encryption is very easy to implement and worth the effort.
  • This includes patient sensitive HIPAA (Health Information Portability and Accountability Act) information (if you are working with healthcare data) and
  • PCI (Payment Card Industry – Data Security Standard (DSS)) information (if you are dealing with payment data).
  • Even if it is just customer data, it makes sense to encrypt or implement a role based security layer to hide personally identifiable data (email, social security numbers, account numbers, zip codes, phone numbers, etc) from unauthorized access.
• Ensure that every screen, module and functionality in the application utilizes role-based security.
• Refrain from creating User / Password tables for individual applications.
  • Use Active Directory or LDAP Integration into active directory to consolidate the security credential repository within the enterprise.
• If your applications perform data exchange over TCP/IP protocols, irrespective of whether the data is sensitive or not, utilize encryption mechanisms like HTTPS, SSL, SSH, SCP, etc.
• Refrain from using weak passwords for applications
• If your application uses a generic account for logging into a network resource or a database, refrain from using that account for personal access.
• Do not hard code the password in code, or even a configuration file. Use the “Log on as” model so that the password can be controlled and changed by system administrators without risking breaking the code.
• Refrain from using generic accounts when you are accessing network or database resources manually (re-iterating on purpose)
• If your application delivers files over the Internet, use SSH. Require the use of SSH for all document exchange.
• Refrain from sending documents as email attachments – reports, etc.
• Place the document in a network / portal folder and send the path in the document as an email.
  • This will not only save network bandwidth and mail server storage space, but also prevent the unauthorized delivery of data in the event that your email gets routed incorrectly or into the wrong hands.
  • By using a UNC path, the person will still have to authenticate into the network to access the document.
• Check Web Applications for SQL Injection checks. If your web server does not comply with SQL Injection protection requirements, stop and ask the Systems or Network administrator to implement a packet filtering firewall.
• Always use session variables for critical security contexts in web applications. Passing variables in both the query string and the form are inadequately secure.
• Always run a security vulnerability test on your web application.
• Always include role-based security test cases with both your unit test and integration test cases so that your implementation’s security is verifiable.

This and a lot more come to mind. But again, this is a brief checklist to ensure that your implement is hack-proof, every good developer / architect should have his own threat-modeling checklist.