Vulnerability framework is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities, in the Sm8 software application, data transmission and business practises.
Vulnerability management is integral to Sm8rtHealth’s Clients website security and network security. Penetration tests and fuzzy testing with relevant test cases can identify certain kinds of vulnerabilities, such as a buffer overflow exploit. Such analyses can be facilitated by test automation.
Correcting vulnerabilities may variously involve the installation of a patch, a change in network security policy, reconfiguration of software (such as a firewall), or educating users about social engineering.
Framework methodology
A three-pronged approach to vulnerability assessments.
Step 1: Determine vulnerability severity:
The severity assessment should be based upon the potential damage that a successful exploit might cause. For example, a vulnerability that gains access to the administrative portal to a system is much more severe than one that causes a denial of service.
Step 2: Identify data sensitivity
The risk of vulnerability is heightened by the degree of sensitivity of the information. Personal identifiable information should be handled with added security feature. The presence of sensitive information magnifies the reputational damage that a public facing website will encounter in the event of an attack.
Step 3: Evaluate existing control
Evaluate the existing controls that protect potentially vulnerable systems from compromise. Use 3rd party expertise as may be required.
Application security
Application security encompasses measures taken throughout the code’s life-cycle to prevent gaps in the security policy of Sm8rtHealth or the underlying system (vulnerabilities) through flaws in the design, development, deployment, or maintenance of the application.
Sm8rtHealth looks to OWASP as an industrial norm in assessing developing and implementing the i-underwrite application. We rely on Open Web Application Security Project (OWASP) and Web Application Security Consortium (WASC) protocol and updates on the latest threats which may impair our web based application. This aids developers, security testers and architects to focus on better design and mitigation strategy.
Application Vulnerability Severity
Sm8rtHealth commissions public facing underwriting engines. Applicants do not log-in to the website, their access rights are limited to viewing information and inputting responses. At no stage do Applicants ever have the ability to modify, edit or delete accepted information.
The vulnerability of the application from an Applicant’s view is limited to malicious attacks from input fields. Users, log into the Sm8rtHealth Workbench portal of the website. Such Users of the system can view sensitive information, modify or delete information and gather sensitive commercial information. Their ability to corrupt of find vulnerable points within the application is greater, and hence the need for staff internal procedures and training
Application Sensitivity Test
The SM8 application gathers personal information through the application process. This information can be broken up into 5 parts with a measure of sensitivity rated for each part in the table below;
| Information Type | Degree of Sensitivity* |
| Personal contact information | 2.5 |
| Personal health information | 4 |
| Personal identification (Id /passport) | 5 |
| Credit Card information | 5 |
| Insurance information | 3 |
Existing controls for browsing and input functionality
The SM8 engine provides as few “free text” input controls as possible to reduce the risk of malicious data entry. Where free text is permitted, or the and input field is required, validation is written into the end-point so as to ensure malicious text can not be ingested.
SM8 validates responses both in the web browser and at the web service layer to minimise vulnerability to risk. Such validation includes restrictive character strings and numerical and date validation rules
SM8 public facing inquiry and technical support web forms require a “Captcha Image” for human input authentication.
