Security is an important part of the design of a solution, and it involves more than just setting up passwords. The solution must first be evaluated to determine the people that will need access and the types of things that they should be allowed to do. For the most part, the security design must ensure that those people can have access to perform those functions. However, other people must be prohibited from accessing the solution, and other functions must be prohibited.

Creating a security risk assessment includes identifying the data associated with your solution, the security level of the data, and the possible threats and vulnerabilities your design should try to address. In addition, your risk assessment should consider the likelihood of the security events occurring and the consequences of each event. This is necessary to ensure that the cost of implementing security measures is appropriate based on the potential vulnerabilities.  

• Access requirements. First, describe the legitimate uses of the solution and the people (roles) that will need access to perform those functions. These are general statements and not detailed requirements. In general, this risk assessment will determine the difficulties in limiting access to these people and functions.
• Data security designation. The first part of the security risk assessment is understanding the security requirements of the underlying data. Highly confidential data, like sales and payroll data, obviously needs to be protected more than data that is for everyone, such as the company open job positions.
• Threats. Threats to information systems can come in a variety of ways.  Normal human error can result in security breaches. This may be the case, for instance, when someone opens an email file containing a virus. There may also be threats from fraud and theft from insiders. One of the most damaging threats to systems is malicious hackers and malicious code sent to a system.  Malicious code includes items such as viruses, worms, Trojan horses, etc.  These threats are real, likely to occur, and bring about a great deal of cost in repairs. You should work with your client to identify the potential threats against your data.
• Vulnerabilities. Vulnerabilities are unintentional security lapses. For instance, your solution may enforce userid/password security, but it may be vulnerable to hackers if these passwords are easy to figure out, like the current date or a person's first name. Another vulnerability may arise because of a program logic error. You may need to put measures in place to guard against vulnerabilities.
• Likelihood and risks. There are two areas that should be addressed for each threat and vulnerability to your system - the likelihood of the threat or vulnerability occurring, and the consequences of the breach. If a threat or vulnerability is likely and the consequences are significant, the solution should have extra security and controls in place to protect the underlying data. If the threat is remote, or the consequences of a breach are relatively minor, you would want to design less costly controls or perhaps none at all.
• Controls / safeguards. Now that you have a general understanding of threats and vulnerabilities and the likelihood of these security incidents, you can determine the controls and safeguards necessary to respond to these risks. Responses could include implementing firewalls, installing software to detect hackers, suspending a userid after three wrong password attempts, providing increased training, etc.

There are a number of security principles that provide guidance for almost all software applications. These include:

• Use a multifaceted security approach. It is a rare solution that only needs one type of security function. You need to look at security from a number of angles and address security concerns across the full spectrum.
• Protect the solution from the IT developers. In many organizations, security is seen as a way to protect an application from clients and outsiders; however, security must also address the vulnerabilities of the IT developers and support staff. This security will protect the solution from malicious hacking, which is rare, as well as inadvertent but still serious “innocent” mistakes made by the IT insiders.
• Fail gracefully and securely. In the past, there was an emphasis on failing gracefully, which meant that the code should fail with helpful messages and the ability to quickly restart. Now, you must also make sure that the code fails securely, and that a fatal error does not open you up to additional security vulnerability.
• Use security tools if appropriate. There are now many tools in the marketplace that will assist in making sure that your software is secure. These can be especially helpful in ensuring that you don’t introduce a security problem based on some obscure set of data values that you would not likely test for.  
• Allow the least privilege necessary for the job. This means that we allow people to have access to what they need to do their job, but not any more than that. 

These are general principles and approaches for handling security in solutions. The exact nature of the implementation of these principles will depend on the nature of your business, your tools and your needs.