Key takeaways from CSA’s SaaS Governance Best Practices guide

Read Time:42 Second

SaaS governance and security is gaining attention among IT and security leaders. This is good, given that organizations are using exponentially more software-as-a-service (SaaS) than infrastructure-as-a-service (IaaS) offerings. Large enterprises are using upwards of 200 different SaaS offerings, compared to two or three IaaS providers, and only about 30% of organizations have any sort of SaaS security solutions in place.

Despite the pervasive use of SaaS, it is overwhelmingly ungoverned with little insight into use, data storage or access control. That’s why the Cloud Security Alliance (CSA) created the SaaS Governance Best Practices for Cloud Customers whitepaper, for which I was honored to serve as its co-lead. These are some of the key security takeaways from the SaaS governance best practices guidance.

To read this article in full, please click here

Read More

How you handle independent contractors may determine your insider threat risk

Read Time:55 Second

If one was to build a Venn diagram to compare the onboarding, educating, supervising, and offboarding of staff versus contract workers, the areas differences might offer a surprise. In this case, surprises aren’t what a CISO wants to encounter. Thus, such a diagram as part of their insider risk threat management program highlights the delta between the two types of workers and how they are handled.

The concept of core and context when it comes to separating the duties of the full-time-equivalent workforce into staff and independent contractors has long been an ongoing challenge for every enterprise and small- to medium-sized business. Add to the mix the contracted service offerings — for example, a managed security service provider — and entities find themselves handing the keys to the kingdom over to a third party to handle tasks at hand. On top of that, the past two-plus years have caused many an entity to undergo a momentous change to how employees/independent contractors engage, with a noted influx in the remote work option.

To read this article in full, please click here

Read More

php-laminas-diactoros2-2.11.2-1.fc36

Read Time:2 Minute, 7 Second

FEDORA-2022-6628e8d771

Packages in this update:

php-laminas-diactoros2-2.11.2-1.fc36

Update description:

Version 2.11.2

Bug

95: Resolve Host header and X-Forwarded-Proto regressions thanks to @weierophinney

Release Notes for 2.11.1

This is a SECURITY release. All users are encouraged to upgrade immediately.

Added

This release adds features to allow filtering a ServerRequest as generated by LaminasDiactorosServerRequestFactory::fromGlobals() for the purposes of initialization. Examples include:

Adding a request identifier.
Using X-Forwarded-* headers to modify the URL to represent the original client request.

The features are based on a new interface, LaminasDiactororsServerRequestFilterFilterServerRequestInterface, which defines a single method:

public function __invoke(
PsrHttpMessageServerRequestInterface $request
): PsrHttpMessageServerRequestInterface

We provide two implementations, as follows:

LaminasDiactorosServerRequestFilterDoNotFilter will return the provided request verbatim.
LaminasDiactorosServerRequestFilterFilterUsingXForwardedHeaders has named constructors that allow you to define how and when X-Forwarded- headers are used to modify the URI instance associated with the request. These methods are:
* trustAny(): this method generates a filter instance that will trust all X-Forwarded-
headers from any source.
* trustReservedSubnets(array $trustedHeaders = ?): this method generates a filter instance that only modifies the URL if the IP address of the requesting server is from a reserved, private subnet (localhost; classes A, B, and C subnets; and IPv6 private and local-link subnets). By default, it will trust all X-Forwarded- headers from these sources, but you may specify a list to allow via the $trustedHeaders argument.
* trustProxies(array $proxyCIDRList, array $trustedHeaders = ?): this method will generate a filter instance that only modifies the URL if the requesting server matches an entry in the $proxyCIDRList. These entries may be IP addresses, or any IPv4 or IPv6 CIDR subnets. By default, it will trust all X-Forwarded-
headers from these sources, but you may specify a list to allow via the $trustedHeaders argument.

ServerRequestFactory::fromGlobals() now accepts a FilterServerRequestInterface instance as the optional argument $requestFilter. If none is provided, it uses one as produced by FilterUsingXForwardedHeaders::trustReservedSubnets().

Deprecated

The function LaminasDiactorosmarshalUriFromSapi() is deprecated, and no longer used internally.

Changed

LaminasDiactorosServerRequestFactory::fromGlobals() no longer consumes marshalUriFromSapi(), and instead inlines an alternate implementation. The new implementation does not consider X-Forwarded- headers by default when generating the associated URI instance. Internally, if no FilterServerRequestInterface implementation is provided, it defaults to using an instance returned by FilterUsingXForwardeHeaders::trustReservedSubnets(). If you previously relied on X-Forwarded- headers, you MAY need to update your code to use either the FilterUsingXForwardedHeaders::trustAny() or FilterUsingXForwardedHeaders::trustProxies() methods to generate a filter to use with ServerRequestFactory::fromGlobals().

Fixed

Fixes CVE-2022-31109

Read More