A trustworthy software application that needs to withstand malicious attacks should follow the SD3+C.
A multi-layered software application must at least approach data security and data access as what Microsoft refers to a SD3+C framework: Secure by Design, Secure by Default, Secure in Deployment and Communications. If your software application is intended to be used to process personal or sensitive information, or to be used in an enterprise or other organization, or to be connected to the internet or network environment it is imperative for software to have the following criteria’s:
Roles-based User Rights
Roles-based user rights provides users to specifics areas of the software or partitions based on login permissions set by the administrator to accomplish the tasks assigned to that user’s rights.
A user may have different rights in different parts of the enterprise. For example, a user may be able to enroll new card holders for an office in Houston, but not the Austin office or not have access to specific features of the software, such as visitor management or badge creation.
No Default Password
An often-over-looked security vulnerability is default passwords. Many systems contain them and many never get changed. A quick internet search for “default passwords” under a specific access control product will turn up the factory default, which also means that a perpetrator looking to get into the system will do the same.
Each system should be issued with a unique password. This is really the first step in designing with both human nature in mind and secure by design philosophy.
A trustworthy computing system should protect the transmission of data between the client and the cloud based server using modern TLS 1.2 encryption. This same technology is used to secure credit card information, social security numbers, and login credentials. TLS 1.2 is essentially the next step in the evolution of encryption and has replaced SSL. All data in transit (moving from or to the host) should be protected by TLS 1.2 encryption while data at rest (once the data reaches the servers) should be protected with server-side encryption (SSE).
No accessibility to the Database
There should be ZERO access to the database. All activity related to the database must pass through an SOAP or RESTful API. The Database should reside on its replica and set behind a firewall in an encrypted state.
User activity audit logs are first class citizen with the rest of the event pipeline. Alerts can be generated (email, SMS, mobile, WebHooks) for data modification just as for door access. For example, send the user a text after two successive failed login attempts.