Why RAID.Cloud?

Fraud remains a big challenge for the telecommunications sector. Fraud is persistent, invasive and harms customers and institutions alike. Fraud threatens to compromise not just business results, but also customer relationships and the market’s perception of a brand.

As the shift to cloud-based services increases, fraud management capabilities can be delivered as hosted services to help drive more operational efficiencies and to improve business agility. WeDo Technologies’ RAID.Cloud combines the power of a reliable fraud management solution with the benefits of a hosted, cloud-based deployment model.

Around the world, more than 40 organizations rely upon WeDo Technologies’ Fraud Management solution for its world-class ability to detect and prevent telecom fraud. The solution works across a variety of fraud types and technologies – including mobile and fixed, and provides a protective barrier for all the new digital services that are driving changes in the telecommunications industry today.

SECURITY STANDARTS

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