Solution Security

Applications that store personal information along with the payment information are a subject to compliance regulations like HIPAA and PCI-DSS.

We treat data and application security as a never-ending challenge that should be constantly enforced in code, development practices, testing, employee training and ongoing vigilance. With proven expertise in secure software development we help clients to create custom software solutions and ensure data and application security of their software.

BUILDING SECURE APPLICATION ARCHITECTURE

The process of creating application architecture should always be undergone with the security in mind. Unless it is, implementing security policies after the application or software is already on the market will not be of much use in drastically decreasing system vulnerabilities.

There are several key steps that can help better understand the security requirements:

  • Describe existing architecture in details. Break down software architecture into individual ties.
    Best application architecture approach is to have multiple layers to separate various functional parts of the system into logical block. For example, front-end, mid-tier and data management layer. This approach allows applying different security methods and practices for each of the layers minimizing the threat of the breach.
  • Define and describe coding practices that are currently used. A lot of the commonly exploited vulnerabilities are a result of poor software development coding practices. At Kanda we leverage best programming techniques for every language paired with our rigorous integrated quality assurance processes. This approach minimizes the number of software “bugs” created in the process and, subsequently, the amount of time to fix them.
  • Do you have security assurance? What is the application testing process, if it exists. Formal security and quality assurance program is the best approach to ensure proper application development process. All application modifications should undergo both automated and manual testing, including full performance and vulnerability testing before the commercial deployment.
  • What vulnerability assessment and testing methodology is used?  Web-application and SaaS systems should be routinely tested for vulnerabilities to ensure that application enhancements, server upgrades and new feature roll-outs will not lead to security vulnerabilities.

Our Software development teams practice Regulatory Compliant Cloud Computing (RC3) practices when building and implementing solution architecture for our clients.

Following RC3, the data is usually classified into 3 categories. The data-modeling section of RC3 simplifies communication between business units and IT. There was no confusion about the security/regulatory requirements for any given data-element – this effectively provides one of the most secure data-architectures from the ground-up.

RC3 Data Classes:

  • Sensitive and regulated data. Data whose disclosure to the public would result in fines, potential law suits, and loss of goodwill to the breached entity. Data examples: Credit Card data, payment and purchase information
  • Sensitive but non-regulated data.Data which is not regulated, but whose disclosure to the public would be detrimental to a company and/or result in some loss of goodwill to the breached entity. Data examples: User information, including personal details and e-mails, business information that consisting of business names, questionnaire responses and any other business sensitive data.
  • Non-sensitive data – All other data.

 

ENSURING DATA SECURITY

No matter what web-based application solution you are developing or planning to develop, most likely it will contain sensitive user data that needs to be protected. With online and mobile payments on the rise, protecting customer data has become important like never before. Business application domain is a special case that requires sophisticated encryption and security algorithms.

Applications that store personal information along with the payment information are a subject to multiple compliance regulations like HIPAA and PCI-DSS.

According to RC3 methodology Class 1 and Class 2 data is encrypted, tokenized, processed and stored in regulated zones, within a secure network perimeter – outside the public cloud where the application is hosted – in compliance with applicable data-security regulations. Since Class 3 data is declared to be non-sensitive, it is processed and stored – unencrypted – in the public cloud.