<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

Application owner challenges: security and compliance concerns

Application Owner local_offer

One of the chief benefits of an application owner program is to address security updates proactively. Rather than reactively detecting and prioritizing updates based on security scans for known vulnerabilities already present in the environment, an application owner can initiate an update request. Such certainly does not remove the need for security scans, but with an effective application owner implementation in place, the number of detected vulnerabilities should decrease.Some basic understanding of Security is increasingly necessary for even non-technical staff, but even more so for Application Owners. Some basic concepts are necessary to understand in order to help assess when an application should be updated for security reasons. Namely, a rudimentary understanding of terminology and metrics commonly used to communicate the criticality of vulnerabilities and security fixes.

Terms like “critical” and “moderate” are self-explanatory, but the common method of relating CVSS scores is not. A CVSS score is a criticality score ranging from one to ten, with ten being the most critical. Many organizations have a policy of addressing those with higher scores within a set period of time. For example, anything with a CVSS score of seven or more must be updated within five days.

When available, threat intelligence metrics can be more valuable as they help identify the likelihood of exploitation (versus the potential damage CVSS is used to communicate). Higher threat levels would be associated with vulnerabilities that are actively being used to do harm and would be the highest priority to reduce risk to the organization. Such threat intelligence is common among security solutions to the extent it is not uncommon to have more than one source of information available, as many enterprise organizations employ multiple security tools.

While this is helpful to understand, it will still mean that urgency might be appropriately applied to some update recommendations over others. From the perspective of an application owner, the existence of any security fixes at all is a sufficient data point to justify an update recommendation. Although any security fix in a new version gives some weight to justify an update should be deployed, the security or operations teams must still prioritize the order in which they work to handle the updates based on criticality. Just how this is done is not necessarily something the application owner must understand, but it is important to realize that update recommendations may not translate to a rapid response amid other competing (and more serious) patching efforts. 

In some cases, there may also be compliance standards an organization must consider, which might impact the decision to adopt third-party application updates at all. Generally speaking, new updates resolve these kinds of concerns rather than injecting new concerns, but depending on the application and needs of the organization, an understanding of what to watch out for may be important for an application owner. Compliance isn't just a checklist but a continuous commitment to maintaining standards across various domains, from financial regulations and data protection laws to industry-specific standards and accessibility requirements. For instance, updates in financial tools should align with Sarbanes-Oxley Act requirements, ensuring data accuracy and proper audit trails. Similarly, updates to healthcare applications must respect patient privacy as per HIPAA, ensuring no unauthorized data sharing occurs.

Each of these examples underscores the multifaceted role of an Application Owner, who must juggle the technical aspects of application management with the broader implications of compliance and security. This role, therefore has within it elements of risk management, legal compliance, and organizational strategy. The Application Owner becomes a crucial link between the technical and operational realms, ensuring that software updates enhance functionality without compromising on regulatory obligations or security.

Below is a summary of some popular compliance standards and regulations enterprises must frequently consider in the adoption of new and updated software. 

  • Financial Regulations (e.g., Sarbanes-Oxley Act, Basel III):
    • Example: A new version of a financial reporting tool may not adhere to the stringent data accuracy and audit trail requirements mandated by Sarbanes-Oxley.
    • Implication: This could lead to inaccurate financial reporting, legal repercussions, and a loss of investor confidence.
  • Accessibility Standards (e.g., ADA, WCAG):
    • Example: An update to the organization's website or client-facing applications that fails to comply with WCAG 2.1 AA standards could make the application inaccessible to individuals with disabilities.
    • Implication: This could lead to legal challenges under the ADA and damage the organization’s inclusive reputation.
  • Industry-Specific Standards (e.g., ISO 27001, PCI DSS for Payment Systems):
    • Example: An update to a payment processing system might not be compliant with PCI DSS standards, potentially leading to vulnerabilities in handling credit card information.
    • Implication: Breaches could result in hefty fines, legal action, and loss of customer trust.
  • Export Control Regulations (e.g., ITAR, EAR):
    • Example: A software update could inadvertently allow users in embargoed countries to access controlled technology or data, violating ITAR or EAR regulations.
    • Implication: This could lead to severe legal consequences, including fines and sanctions.
  • Data Protection and Privacy Laws (e.g., GDPR, HIPAA):
    • Example: An update to a healthcare management application might introduce features that inadvertently share patient data with third-party vendors, violating HIPAA regulations.
    • Implication: Non-compliance could result in significant fines and damage to the organization's reputation.
  • Industry Compliance (e.g., FERPA in Education):
    • Example: A new feature in an educational app might inadvertently expose student records, breaching FERPA guidelines.
    • Implication: Non-compliance could lead to federal funding cuts and legal issues.