Application Security Policies Ideas

 Application Security Policy ideas. A thread for my #infosec friends ...

Make your policy applicable to all applications (internal, external, 3rd party hosted, custom built, off the shelf, outsourced, etc)

Require configuration management (change controls , CMDB, etc)

Require Testing evidence and approval prior to deployments

Require Vulnerability management and patching on a cadence , make sure to include all 3rd party add-one, libraries, and dependencies

Ensure separate environments for production vs non-production (different servers , different accounts , different databases)

Require Separation of Duties including code reviews performed by someone other than the developer and deployments done by someone other than the developer 

Require logging (authentication, web , database, OS level, administrative logs) , store logs on a secondary system like a SIEM and prevent tampering.

Developers must perform input validation regardless of the source (text fields , url parameters , API parameters, input files, etc )

Passwords must be hashed and salted at rest , encrypted in transit , must meet a complexity policy that includes preventative commonly used ones, and passwords resets should occur using temporary expiring links.

Applications must include access control , at a minimum separating users from administrators.

Applications must follow least privilege for users and service accounts ensuring the accounts only have access to the functionality they require.

Sensitive data must be encrypted at transit and at rest.

Data should never be copied from Production to Non-Production without first being sanitized of sensitive data.

Purge data that is beyond required retention periods , and purge unused code , screens, and dependencies to reduce the attack surface.

Error screens displayed to users  should not display code , technical detail or stack traces .

Administrative screens should not be public facing , but instead require VPN or internal network access to administer.

Contracts with software providers , hosters, development teams , etc should define who owns the data, who owns the compliance requirements, and also include SLAs for vulnerability response , incident notification and response.

Newly on-boarded developers must complete security training and read all security policies prior to writing any code. 

Code reviews must check for the OWASP Top 10.

Source code must be stored in version control that records who made what changes and when.

Test websites should not be publicly exposed but instead require VPN or internal network access.

Email addresses on public facing sites should not be scrape-able to minimize malspam/phishing attack surface.

After any major changes , vulnerability scans must be re-run and the CMDB must be updated.

Require a re-occurring cadence of penetration testing your application from a source outside of your own team.

Have an emergency patching procedure and communication plan in place and test it on a cadence.

Implement all security gardening procedures provided by 3rd parties including at the application , web, database, and OS level.

Monitor and proactively ensure you prevent any end of life , end of support, or licensing restriction issues that could impact your ability to perform incident response.

Document and get the data owner’s approval for any exceptions to the application security policy.

Hope this helps you in your application security policy adventures my #infosec friends!