Quoin delivers pragmatic guidance and hands-on assistance for organizations that must ensure secure, robust, and performant systems. Our work encompasses the full scope of enterprise systems – package applications, web applications, legacy databases, and devices such as scanners. Our senior technologies and project teams use a disciplined approach for identifying and fixing operational vulnerabilities. 

• Security Audit – Conduct a hands-on review of implementation practices, deployment, production servers, monitoring, security policies, and other aspects of an operational environment to identify potential vulnerabilities
• Quality Audit – Evaluate the source code, production infrastructure, testing, issue tracking, deployment, remediation, and other practices that determine software quality
• Software Verification – Implement a regression system testing suite for an application to verify conformance to specifications, performance, security, robustness, and other qualities
• Quality Improvement – Provide an independent team to test and fix software using a sophisticated set of code quality and analysis tools to yield improved security, robustness, or performance.

Security Principles

Security and robustness require a comprehensive understanding of a system – evaluating how the system was implemented to its use introduction. A Quoin project team uses a methodology based on the following principles.

Use best practices – 

• Security and robustness require a comprehensive understanding of a system – evaluating how the system was implemented to its use introduction. A Quoin project team uses a methodology based on the following principles.
• Use best practices – Securing systems is quite involved where one design, deployment, or configuration error can compromise a system. Basing security on well-designed and generally accepted guidelines will reduce the risk and cost of securing a system.
• Minimize exposure – This guideline is sometimes referred to as “minimizing attack surface”. It involves reducing the number of interfaces that a system exposes to reduce the risk of compromise. An example is removing an installation of Apache from a host if it is not required.
• Defense in depth – Defense in depth provides a layered set of security mechanisms to increase overall system security. If an attack causes one security mechanism to fail, other mechanisms continue to protect the system. An example is configuring UNIX system accounts to both disable login and set the login shell to /usr/bin/nologin. If an attacker manages to defeat the login disablement, the nologin shell will still prevent access to the system. Defense in depth must be balanced with the simplicity principle.
• Least privilege – Least privilege restricts the user and group accounts that a service runs as to the minimum required to perform their required functionality. This includes both restricting user/group rights and access to resources such as the file system, network, memory, and CPU.
• Fail securely – Fail securely mandates that on a configuration error or security failure, the default setting or action maintains security. An example is setting the default policy on a firewall ruleset to “deny”.
• Simplicity – Security tools and processes that are difficult to understand, implement, or validate are susceptible to misapplication leading to vulnerabilities.
• Active monitoring – Maintaining the security level of a system is not a one-time exercise. Active monitoring is required to verify the current configuration, scan for newly discovered vulnerabilities, and detect any intrusions.

Do not trust default configuration, third-party services, or infrastructure – A common misconception is that the default configuration for a system as provided by a vendor will be inherently secure. This is rarely the case since the incentive is to minimize support calls which usually results in a permissive configuration.

Quality Principles

The quality of a system similarly depends on a comprehensive approach including the development process and the resulting code. Our approach uses the following principles.

• Build-in quality – Quality should be intrinsic to the entire development process and starts with well-formed user stories that include acceptance criteria, and preferably executable tests.
• Write tests first – Developers write unit and system tests before any code – this approach enables the team to identify requirements or design issues early in the development process.
• Test components – Developers write unit tests as the code is developed. These tests immediately verify the correctness of newly-coded functionality.
• Automate tests and builds – Implementing these complex processes allows developers to quickly verify new functionality and identify any adverse side-effects. Unit tests are incorporated into the application’s test harness to support regression testing for each build.
• Practice continuous integration – Developers integrate their code with the project repository several times a day. This technique ensures that all components integrate seamlessly and that integration failures common to other projects are avoided.
• End-to-end testing – At the completion of each iteration, the team will test end-to-end system functionality. Such testing covers system workflow from start to finish of key processes.
• Release frequently – A team delivers new functionality as part of a stable, testable, and visible release candidate every four to eight weeks, regardless of the size and length of a project. This discipline allows a team to quickly identify problems and react accordingly.

Performance Principles

Performance is seldomly driven by a single root cause – diagnosing and fixing poor performance requires methodical analysis and strategy for remediation. Our approach uses the following principles.

• Find the problem – Use a performance profiler or instrumentation of the source code to identify bottlenecks.
• Be creative – Performance fixes can be as simple as changing a few service calls or optimizing data interchange. However, more frequently, a re-design of the entire API is needed. The key here is to not just attempt a quick fix but to be open to possible solutions.
• Build a proper testbed – All organizations need a test environment that replicates production as much as practical. Performance tuning, except in the simplest cases can only be done in an isolated environment where improvements can be evaluated. This can require a lot of work -- server configuration, defining test data sets, scripting set up, and tear-down – but is the only approach that yields consistent results in tuning.