Deutsch | English
Improve Defenses and Maintain Constant Vigilance Against Attacks
The PLYNT ℠ certification program is an award-winning security assurance program from PLYNT ℠ (the Paladion's security testing unit), which was launched in 2006 by software development companies, SaaS, PaaS, software providers, software service providers, and organizations involved in the development of their software employ their own web applications.
We have designed the PLYNT ℠ certification program for commercial and custom web applications so that we can design the penetration test according to your needs and certify your website from a security perspective. With the PLYNT ℠ certificate in hand, your product managers and developers can prove to customers that the applications conform to very strict security criteria and are well secured against attack.
The PLYNT ℠ certification program measures a each application's ability to defend itself against relevant and specific threats. The application is tested against a comprehensive set of global security and vulnerability standards and guidelines such as OWASP, SB1386, OSSTMM, SEC 17, SANS, CWE Top 25, SOX, WebAppSec, HIPAA and PCI DSS.
Placing the order can be done quite unbureaucratically through Email
We’ll use the information you give us to determine the possible threats your app might be susceptible to. We’ll conduct the penetration test at your convenience and deliver a detailed, easy-to-read report that will give you a complete profile of your security vulnerabilities and the ways to fix them. That report serves as a starting point with solution pointers to secure your site.
Our report will give you all the guidance your development team will need to test our solutions to fix the vulnerabilities we’ve identified. If you encounter a problem or have any questions give us a call or email us..
We’ve run the tests and your development team has had a chance to fix the problems. Once the new version is ready for testing, we will conduct a full regression test. If we find no vulnerabilities, we will issue you the PLYNT ℠ Certificate of good health. Any time you need us after that we’re only a phone call or an email away. We are always ready to conduct additional tests.
Note: A list of the popular attacks we test for is present under the “Guide to the PLYNT ℠ Certification Criteria” section.
Note I: A threat describes the goal of an adversary. According to the National Information Systems Security Glossary, a threat is any circumstance or event that has the potential to harm an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
Note II: The threat profile is a list of all possible threats an application faces, but in this criterion we focus on threats related to business and authorization rule violations,because other threats are covered by the rest of the criteria.
Note I: The criterion requires that even after a user logs out, the user’s password or passphrase must be protected from theft.
Note II: The criterion recognizes that there are social engineering methods that could be used to steal the password or passphrase without access to the application. These are not within the scope of this criterion.
Note III: The risk of password guessing varies depending on the predictability of the usernames used by the application.
Note I: An alternate authentication mechanism may include implementations like security questions, or one-time passwords sent to a user-owned device like mobile phone or other token devices.
Note II: A secure mechanism for password issuance entails the use of tokenized links, temporary passwords, and SSL communication while resetting the password.
By password we mean any secret that is used during an authentication process, for example, passphrase, PIN, passcode and passkey, etc.
Note I: This criterion includes securing all directories, backup, log and configuration files. Configuration files include OS, web server and application configuration files.
Note II: Along with the HTTP(s) service on which the application is accessible, this criterion mandates protection of all the non-HTTP(s) services like SSH, RDP, FTP, etc. against attacks that would lead to server compromise, which would eventually affect the web application.
Note: The security of interactions specified in this criterion includes cross-domain origin checks and session management checks for web client components like Javascript, applets, Flash, HTML5, and Web sockets.
Note I: Easily accessible locations include the browser cache, the browser history, web storage, other browser menus and persistent cookies on the client machine.
Note II: The browser memory is not considered an easily accessible location for this criterion.
Note: Sensitive information includes not only business-sensitive information but also details regarding application architecture that could aid an adversary who is attempting to launch an attack against the application.
Note: The secrets in the above criterion refer to cryptographic keys, passwords and algorithms that are considered trade secrets.
Note: This criterion does not apply to the special case where the user has forgotten the password and resets the password using the application’s password recovery or “Forgot Password” feature.
Note: Sensitive data, as used in this criterion, include personal identity, personal health and payment card information, as well as session token(s) and authentication token(s).
The application must demonstrate its defence against threats specified in a Threat Profile that has been developed specifically for the mobile application.
Self-signing the recompiled APP build can breach the trust of users, as it contains modified data. An attacker can upload the replica of the APP to the store with a relevant name, wherein the details of legitimate users get exposed.
The application must ensure that untrusted input is validated before it is used by any device resource. The application must not abuse the device resources.
Operating Systems implement functionalities that use mobile OS-related features. The application must implement these features securely, without introducing vulnerabilities.
The application must demonstrate adequate measures to protect sensitive data from being accessed whenever the device is lost or stolen. The application must not store sensitive data in the local storage, APP installation and property files.
The application must not leak data through channels such as the application cache, logs, temporary directories, etc. wherein the data is usually retained indefinitely.
The application must demonstrate, through testing, that it is not vulnerable to popular server-side attacks.
The application must take adequate measures to protect sensitive data from being stolen over the network. It must protect the data in transmission by implementing strong encryption.
Mobile applications connect to backend services in order to send and receive data. These services must be protected against vulnerabilities that are directly exploitable throughout the application.
The backend server must be updated and protected against known vulnerabilities. The web service running on the server that houses the application must not be vulnerable to publicly known exploitable vulnerabilities.
The application must not retain hardcoded data like passwords and encryption keys.
The application’s source code must be protected against data leakage, while disassembling the application package.
The application must re-authenticate the user before allowing the user to perform an operation involving sensitive data. Examples of operations involving sensitive data are Change Password, Payments and Transaction Approval..