Additional Security Controls

In addition to encryption, authentication, and input validation, the Veonics® Portal includes a range of supporting security practices.

🛡️ In addition to encryption, authentication, and input validation, the Veonics® Portal includes a range of supporting security practices covering authorization, configuration management, sensitive data handling, session management, cryptography, parameter handling, exception handling, auditing, and vulnerability scanning.

These practices are aligned with OWASP recommendations, NIST CSF 2.0, and AWS cloud security best practices.

4. 🔑 Authorization Controls

• Server-Side Access Control: Yes — enforced via RBAC and organizational hierarchy.

• No Reliance on Client Data: Hidden fields, cookies, or headers are not used for authorization.

• Role-Based Approach: Yes — Admin, Production, Subscription, and Customer roles.

• Authorization Code Enforcement: Yes — applied consistently at page and API levels.

• Database Access: Yes — via stored procedures/parameterized queries.

📄 Supporting Docs: Security Roles & Responsibilities in the Veonics Ecosystem

5. ⚙️ Configuration Management

• Remote Administration Supported: Yes — restricted to Admins via secure channels.

• Strong Authentication: Yes — TLS, MFA for elevated roles, restricted IAM roles.

• Encrypted Remote Access: Yes — IPSec/VPN with jump-box controls.

• Configuration Store: No -  Stored outside web space, access limited to approved Admins.

• Data Security: Config files encrypted and protected in AWS.

• Access Restrictions: IAM policies and least privilege enforced.

• Separation of Privileges: Yes — Admin rights are separated from user rights.

📄 Supporting Docs: Access Control & Remote Access Policy

6. 🔒 Sensitive Data Handling

• Secrets in Config: Yes, stored securely (encrypted in AWS).

• No Secrets in Cookies: No, and never stored in cookies.

• Strong Encryption: AES-256 in AWS; not Triple DES (legacy).

• Key Security: AWS KMS manages key lifecycle securely.

• Data Transmission: TLS 1.2+ only.

• No Logging of Sensitive Data: PII never logged in plaintext.

📄 Supporting Docs: Data Retention & Deletion Policy

7. 🕑 Session Management

• No Plaintext Session IDs: Never sent over unencrypted channels.

• Encrypted Session Cookies: Yes — flagged with Secure and HttpOnly.

• No Query String Session IDs: Not permitted.

• Session Lifetime: Configurable; default ≤15 minutes idle timeout.

📄 Supporting Docs: Endpoint Protection Policy

8. 🔐 Cryptography

• Custom Crypto: No — only industry standards.

• Encryption Algorithms: AES-256, TLS 1.2+ (Triple DES not used).

📄 Supporting Docs: Cybersecurity & Compliance Overview

9. 📥 Parameter Handling

• Sensitive Data in Queries: No — scoped data passed only via secure APIs/forms.

• Input Validation: Yes — aligned with OWASP Input Validation.

• No Security Decisions from Headers Alone: Authorization does not rely on HTTP headers.

10. ⚠️ Exception Management

• Structured Exception Handling: Yes — implemented consistently across the codebase.

• Custom Error Messages: Yes — prevent leakage of stack traces or system details.

11. 📝 Audit & Logging

• Failed Login Auditing: Yes — failed login attempts are logged and monitored by SOC.

• Audit Other Key Operations: Yes — Customer-facing audit logs are available in each badge record, and a custom dashboard on the home page provides consolidated data in a user-customizable form.

📄 Supporting Docs:

• How do you customize the Home page Portlets?
  

12. 🧪 Vulnerability Scanning & Penetration Testing

• Vulnerability Scans: Yes — performed quarterly via Fortra VM solution.

• Penetration Tests: Yes — performed annually with reports available under NDA.

📄 Supporting Docs: Vulnerability & Penetration Testing Process

📊 NIST CSF 2.0 Alignment