Introduction
Security is integrated throughout the WXP software development and operational lifecycle. WXP applies security reviews, thereat modelling, testing, vulnerability scanning, monitoring, and incident response processes to help identify and address security risks.
This article describes how WXP incorporates security into software development, texting, and day-to-day operations.
HP Secure Software Development Lifecycle (SSDL)
HP uses a Secure Software Development Lifecycle (SSDL) to integrate security throughout the software development process.
The SSDL helps WXP:
Reduce the cyberattack surface via secure software architecture
Minimize code-induced vulnerabilities
Protect customer data and identities
HP incorporates security procedures and milestones reviews throughout the SSDL process and provides ongoing security training for software architects, developers, test engineers, program managers, and their leadership teams.
HP includes specific security related procedures in its SSDL processes, performs milestone reviews to ensure security processes are successfully completed, and delivers on-going security training to its software architects, developers, test engineers, program managers, and their leadership teams.
The seven stages in the SSDL process are defined below:
Order | Stage | Description |
|---|---|---|
1 | Training | Covers the SSDL process, security-enhanced design, threat modeling, and secure coding |
2 | Requirements | Incorporates security planning and feature-level security risk assessments at the beginning of development |
3 | Design | Defines and documents the security architecture and identifies critical security components |
4 | Implementation | Implements the security and mitigation approach, including peer code reviews and validation |
5 | Verification | Uses dynamic code analysis, fuzz testing, and attack surface reviews |
6 | Release | Verifies that SSDL requirements have been met and that no known vulnerabilities remain |
7 | Response | Executes the response activities defined during the release stage |
Security Testing
WXP incorporates security reviews and threat modeling into the software development process. New functionality undergoes threat modeling and a security architecture review before software development begins. Minor enhancements are also reviewed periodically.
The WXP development team also performs architecture and code reviews that include security analysis.
Minimum security tests
Before beginning the software development of new features, WXP also undergoes a security architecture review by HP Cyber Security:
Test area | Examples of security tests |
|---|---|
WXP application | Cross-site scripting (XSS), phishing, authentication token theft, input fuzzing, email spoofing, SQL injection, cross-site request forgery (CSRF), and other common web vulnerabilities |
Cloud services and analytics infrastructure | Authentication and authorization interface testing, tenant isolation testing, SQL injection, remote code injection, denial-of-service (DoS) attacks, and input fuzzing |
WXP across supported operating systems | Installation and application integrity, privilege escalation, man-in-the-middle (MITM) attacks, input fuzzing, command verification and data integrity checks, certificate store poisoning, broken authentication, and security configuration |
The WXP development team follows a secure software process, including security reviews and architecture assessments. They conduct infrastructure scanning with tools like Nessus agent. Coalfire independently audits these practices for ISO 27001 certification and SOC 2 Type attestation.
Independent Verification
Internal penetration testing
As part of HP’s Security by Design framework, WXP undergoes continuous internal penetration testing by HP Cybersecurity when major system changes or new features are introduced.
External penetration testing
WXP also undergoes penetration testing annually by an independent third-party security firm.
The assessments cover internet-facing components, the WXP Agent, and relevant cloud infrastructure components.
AI Security and Model Lifecycle
WXP AI models follow a secure, controlled lifecycle that includes security and privacy reviews, training and validation, deployment and monitoring, and periodic reassessment.
Stage | Description |
|---|---|
Design and Review | Each model is reviewed by product, privacy, and security teams. |
Training and Validation | Models are trained on identified data and evaluated against defined performance metrics. |
Deployment and Monitoring | Approved models are deployed to production with automated drift detection and continuous monitoring |
Periodic Reassessment: | Models are retrained and re-validated to ensure sustained accuracy and compliance. |
All AI components are included in the platform’s penetration testing, vulnerability management, and incident response processes.
Service Monitoring
WXP provides regular service updates to communicate new features, updates, and scheduled or unscheduled service changes. For planned service interruptions, such as maintenance, customers are notified eight hours in advance.
WXP and the WXP Agent are monitored 24 hours a day, 7 days a week, 365 days a year for reliability and performance. Network performance and availability are also monitored continuously.
Tool | Purpose |
|---|---|
Splunk | Provides continuous monitoring of system components and near-real-time performance metrics. Most applications and services are instrumental for Splunk to support continuous observability. |
Amazon CloudWatch | Monitors provisioning events, service failures, and threshold conditions such as memory consumption. |
Monitoring tools sent issues, warnings, and problems to service engineers. Exceptions are automatically raised in the internal ticketing system as high-priority work items that require acknowledgement.
WXP also notifies customers through various methods of scheduled or unscheduled updates and changes to the service.
Incident handling and escalation
Escalation
When a monitoring threshold is exceeded, WXP automatically escalates the issue by:
Sending an email alert to the on-call support engineer.
Sending a push notification to the on-call engineer’s mobile device.
Sending an email to the Operations Team distribution list.
Incident review
Incidents are reviewed and categorized based on their severity. Depending on the priority, corrective actions are taken immediatly or scheduled for later development.
Post-mortem quality-of-service (QoS) meetings are held to review findings, identify root causes, and implement improvements.