ANSWER

Cybersecurity is a broad domain with many disciplines. There are several certifications such as the Security+ (Sec+) and Certified Information Systems Security Professional (CISSP) that dive deep into security. The International Institute of Business Analysis (IIBA) offers a certification for Business Analysts who want to specialize in cybersecurity called the IIBA-CCA. Not all business analysts need to be security professionals, but most business analysts will need to be familiar with at least some security principles for their role.

Here are some general security considerations. 

Access Control

• Password Requirements. Make sure systems require strong passwords. Passwords less than 10 characters long can typically be cracked in under an hour; passwords that are 15 characters long can take up to 1,000 years to crack even if they are only lowercase letters.
• Multi-Factor Authentication (MFA). It is becoming common to require more than just a password to log in to any system. MFA requires at least two of: something you know (password, pin, answer to a security question, etc.), something you have (text message with code, smart card, physical token, etc.), and something you are (fingerprint, voice recognition, etc.).
• Principle of Least Privilege. Systems should ensure that access can be broken into small enough pieces to ensure that each account is limited to viewing only the data or accessing only the areas or an application that they need in order to perform their job. This prevents data (salary information, protected health information, etc.) from being exposed to people who shouldn't see it. This also ensures that if an account is hacked, the hacker is limited in the data they can see. If a hacked account has too much privilege, the hacker can potentially extend the access that account has by granting it additional permission, which allows them to access even more restricted information or application areas.
• User and Non-User IDs. The system should allow user IDs that can be assigned to individuals. These are used by people to log in to their normal everyday accounts. The system should also allow the creation of non-user IDs that are used to run system processes. Each non-user ID should be assigned to one owner, and that account ownership should roll over appropriately if the assignee is no longer an appropriate owner.
• Logging. Systems should store user actions (edit, update, delete, etc.) and data changes. This can be used in the event of an audit. Logging ensures "non-repudiation," which is the assurance that someone cannot deny their ID is the account that made the data change.

Vulnerability Management

• Plug-In Components. Developers often use plug in components that they download from external repositories. They should ensure that these components are free from any known vulnerabilities prior to using them.
• Vulnerability Scanning. Vulnerability scans should be run on any system prior to deployment to make sure it is not vulnerable to attacks. There are several tools that can be used to scan code and systems. After the system is deployed, ongoing vulnerability scans should be run and a plan should be in place to remediate any issues.
• System/Software Patching. Patches should be applied on a regular basis to make sure that any known issues are addressed.

Risk Management

• Data Back-Up Plan. Application data should be backed-up on a regular basis in the event that the working data becomes corrupt. The method and frequency used to back up the data as well as its storage location will depend on how critical the data is and how frequently it changes.
• Disaster Recovery Plan. All businesses should have a disaster recovery plan. Included in that plan should be the order that systems need to be shut down and the order they should be restarted. New systems (especially critical ones) should be included in the disaster recovery plan. Where the system falls in the disaster recovery plan will depend on its function and its criticality.
• Regulation Compliance. Ensure that any new system complies with any necessary industry standards such as Health Insurance Portability and Accountability Act (HIPPA), Payment Card Industry (PCI), and others.
• Threat Models. A threat model is a diagram that represents the potential areas where an application or system can be compromised (by bringing it down, falsifying data, escalating user access privileges, etc.) and ways to minimize those threats. A threat model should be completed for any new systems (especially critical systems or externally facing systems).

This is not a comprehensive answer. This touches just some of the main criteria for application security. There are many more correct answers.

--
Shawna Burkey
LinkedIn Profile