Back to offer Raidcloud arrow icon

SECURITY STANDARDS

RAID.Cloud is ASVS Level 2 Certified, this means it adequately defends against most of the risks associated with software today. In addition to penetration testing, level 2 requires at least some access to developers, documentation, code, and authenticated access to the system.

Level 2 is appropriate for applications that handle significant business-to-business transactions, including those that process sensitive information, implement business-critical or sensitive functions, or process other sensitive assets.

Threats to Level 2 applications will typically be skilled and motivated attackers focusing on specific targets using tools and techniques that are highly practiced and effective at discovering and exploiting weaknesses within applications.

  • - All components are identified
  • - All components are identified
  • - All dependencies are identified
  • - A high-level architecture as been defined
  • - Components are segregated
  • - Clear separation between data, controller and display
  • - Client side logic does not contain secrets
  • - Principle of complete mediation
  • - Password fields
  • - Server side enforcement
  • - Fails securely
  • - Allows for strong passwords
  • - All account identity authentication functions are secure
  • - All credential changes are secure
  • - All authentication decisions are logged
  • - Account passwords are salted properly
  • - Strongly encrypted transport
  • - No clear text passwords
  • - No username enumeration
  • - No default passwords
  • - Protects against brute force attacks
  • - External service credentials are encrypted and protected
  • - Password recovery is well implemented
  • - Password recovery can not be used to lock out users
  • - No “secret” questions
  • - Supports configuration to disallow previous passwords
  • - Sensitive operations are sufficiently protected
  • - Block common or weak passwords / passphrases
  • - Use a proven secure authentication mechanism
  • - Protects against username & password disclosure
  • - Admin is not accessible for untrusted parties
  • - Uses default session management
  • - Sessions are invalidated on user log out
  • - Session times out after inactivity
  • - Shows logout link
  • - Does not disclose session id
  • - Session id is changed on login
  • - Session ids may only come from framework
  • - Session tokens are sufficiently long and random
  • - Session cookies have appropriately restricted paths
  • - Does not permit duplicate concurrent user sessions from different machines
  • - User can see and terminate all his sessions
  • - User is prompted for session termination on password change
  • - Authorisation of functions and services
  • - Authorisation of direct object references
  • - Disabled directory browsing
  • - Access controls fail securely
  • - Access control rules are enfoced server side
  • - User and data attributes and policy information cannot be manipulated unauthorized
  • - Has centralized mechanism for access to protected resources
  • - Protects against CSRF
  • - Access control decisions and failed decisions are logged
  • - Protects against fraud
  • - Protects against parameter tampering
  • - Buffer overflows
  • - Rejects invalid input
  • - Input validation or encoding is performed and enforced on the server side
  • - SQL Injection
  • - LDAP Injection
  • - OS Command Injection
  • - XXE
  • - XML Injection
  • - TODO
  • - HTML escaping
  • - Protected against malicious automatic binding
  • - Defends against HTTP parameter pollution attacks
  • - Output encoding/escaping has a single security control per type
  • - Structured data is strongly typed and validated with a schema
  • - Unstructured data is sanitized
  • - Untrusted HTML is sanitized
  • - Auto escaping technology always applies HTML sanitization
  • - DOM writes use safe JavaScript methods
  • - JSON is properly parsed by browser
  • - Data is cleared from client storage on session termination
  • - Crypto fails securely
  • - Random numbers, file names, GUIDs and strings are sufficiently random
  • - Crypto modules have been validated against FIPS 140-2 or equivalent
  • - Policy for cryptographic key management exists and is enforced
  • - PII is encrypted at rest and protected during communication
  • - Keys and secrets are zeroed when destroyed
  • - Secrets are replaceable and placed at installation
  • - Information leakage
  • - Error handling is performed on trusted devices
  • - Logging controls are implemented on the server
  • - Error handling logic denies access by default
  • - Log events are complete
  • - Events that include untrusted data will not be executed
  • - Application log does not include sensitive data
  • - Sensitive data does not get cached
  • - Sensitive data does not get sent in the URL
  • - Temporary client caches of sensitive data are properly cleaned up
  • - Temporary server caches of sensitive data are properly cleaned up
  • - Minimal parameters are sent to untrusted systems
  • - Client side storage does not contain secrets
  • - Accessing sensitive data is logged
  • - Sensitive data is rapidly sanitized from memory
  • - TLS chain is valid
  • - TLS is used for all relevant connections
  • - Connections to relevant external systems are authenticated
  • - Strict Transport Security is used correctly
  • - Forward secrecy ciphers are used
  • - Certification revocation is enabled and configured
  • - Strong certificate hierarchy
  • - TLS settings are current
  • - Only defined HTTP Request methods are accepted
  • - Every HTTP Response contains a Content-Type header with safe character set
  • - Trusted HTTP headers are authenticated
  • - X-Frame-Options is used correctly
  • - X-Content-Type-Options is used correctly
  • - HTTP headers in Requests and Responses contain only printable ASCII
  • - Content-Security-Policy is used correctly
  • - X-XSS-Protection is used correctly
  • - Appropriately uses a trusted environment
  • - Does not allow spoofed high value transactions
  • - Safe from unsafe redirects
  • - Safe from path traversal
  • - Anti-virus scanning
  • - Safe from local file inclusion attacks
  • - Safe from remote file inclusion attacks
  • - Resource sharing
  • - Untrusted files are stored outside the webroot
  • - Deny access to resources or systems outside web or app server
  • - Does not execute uploaded data from untrusted sources
  • - App verifies SSL certificates
  • - App does not use UDID values as security controls
  • - App protects sensitive data
  • - App does not use SQLite for sensitive data
  • - App does not have Secret credentials hard-coded in executable
  • - App protects against auto-snapshot information leakage
  • - App cannot be run on a jailbroken or rooted device
  • - App requires appropriate permissions and resources
  • - App binary has been obfuscated
  • - Web Service client and server use same encoding
  • - Web Service admin is limited to admins
  • - XML or JSON schemas are used properly
  • - Input is size limited
  • - SOAP services comply to WS-I Basic Profile
  • - Session based authentication and authorization is used
  • - REST service is not vulnerable to CSRF
  • - REST service verifies Content-Type
  • - Message payload is signed
  • - No alternative (insecure) access paths
  • - Components are stripped, up-to-date and securely configured
  • - Communication between components is encrypted
  • - Communication between components is authenticated with least privileges
  • - Deployments are adequately sandboxed, containerized or isolated
  • - Deployment processes are secure