Oracle Security Team

Subscribe to Oracle Security Team feed
Oracle Blogs
Updated: 17 hours 17 min ago

Common Criteria and the Future of Security Evaluations

Thu, 2016-10-20 12:08

For years, I (and many others) have recommended that customers demand more of their information technology suppliers in terms of security assurance – that is, proof that security is “built in” and not “bolted on,” that security is “part of” the product or service developed and can be assessed in a meaningful way. While many customers are focused on one kind of assurance – the degree to which a product is free from security vulnerabilities – it is extremely important to know the degree to which a product was designed to meet specific security threats (and how well it does that). These are two distinct approaches to security that are quite complementary and a point that should increasingly be of value for all customers. The good news is that many IT customers – whether of on-premises products or cloud services - are asking for more “proof of assurance,” and many vendors are paying more attention. Great! At the same time, sadly, a core international standard for assurance: the Common Criteria (CC) (ISO 15408), is at risk.

The Common Criteria allows you to evaluate your IT products via an independent lab (certified by the national “scheme” in which the lab is domiciled). Seven levels of assurance are defined – generally, the higher the evaluation assurance level (EAL), the more “proof” you have to provide that your product 1) addresses specific (named) security threats 2) via specific (named) technical remedies to those threats. Over the past few years, CC experts have packaged technology-specific security threats, objectives, functions and assurance requirements into “Protection Profiles” that have a pre-defined assurance level. The best part of the CC is the CC Recognition Arrangement (CCRA), the benefit of which is that a CC security evaluation done in one country (subject to some limits) is recognized in multiple other countries (27, at present). The benefit to customers is that they can have a baseline level of confidence in a product they buy because an independent entity has looked at/validated a set of security claims about that product.

Unfortunately, the CC in danger of losing this key benefit of mutual recognition. The main tension is between countries that want fast, cookie cutter, “one assurance size fits all” evaluations, and those that want (for at least some classes of products) higher levels of assurance. These tensions threaten to shatter the CCRA, with the risk of an “every country for itself,” “every market sector for itself” or worse, “every customer for itself” attempt to impose inconsistent assurance requirements on vendors that sell products and services in the global marketplace. Customers will not be well-served if there is no standardized and widely-recognized starting point for a conversation about product assurance.

The uncertainty about the future of the CC creates opportunity for new, potentially expensive and unproven assurance validation approaches. Every Tom, Dick, and Harriet is jumping on the assurance bandwagon, whether it is developing a new assurance methodology (that the promoters hope will be adopted as a standard, although it’s hardly a standard if one company “owns” the methodology), or lobbying for the use of one proprietary scanning tool or another (noting that none of the tools that analyze code are themselves certified for accuracy and cost-efficiency, nor are the operators of these tools). Nature abhors a vacuum: if the CCRA fractures, there are multiple entities ready to promote their assurance solutions – which may or may not work. (Note: I freely admit that a current weakness of the CC is that, while vulnerability analysis is part of a CC evaluation, it’s not all that one would want. A needed improvement would be a mechanism that ensures that vendors use a combination of tools to more comprehensively attempt to find security vulnerabilities that can weaken security mechanisms and have a risk-based program for triaging and fixing them. Validating that vendors are doing their own tire-kicking – and fixing holes in the tires before the cars leave the factory – would be a positive change.)

Why does this threat of CC balkanization matter? First of all, testing the exact same product or service 27 times won’t in all likelihood lead to a 27-fold security improvement, especially when the cost of the testing is born by the same entity over and over (the vendor). Worse, since the resources (time, money, and people) that would be used to improve actual security are assigned to jumping through the same hoop 27 times, we may paradoxically end up with worse security. We may also end up with worse security to the extent that there will be less incentive for the labs that do CC evaluations to pursue excellence and cost efficiency in testing if they have less competition (for example, from labs in other countries, as is the case under the CCRA) and they are handed a captive marketplace via country-specific evaluation schemes.

Second, whatever the shortcomings of the CC, it is a strong, broadly-adopted foundation for security that to-date has the support of multiple stakeholders. While it may be improved upon, it is nonetheless better to do one thing in one market that benefits and is accepted in 26 other markets than to do 27 or more expensive testing iterations that will not lead to a 27-fold improvement in security. This is especially true in categories of products that some national schemes have deemed “too complex to evaluate meaningfully.” The alternative clearly isn't per-country testing or per-customer testing, because it is in nobody's interests and not feasible for vendors to do repeated one-off assurance fire-drills for multiple system integrators. Even if the CC is “not sufficient” for all types of testing for all products, it is still a reputable and strong baseline to build upon.

Demand for Higher Assurance

In part, the continuing demand for higher assurance CC evaluations is due to the nature of some of the products: smart cards, for example, are often used for payment systems, where there is a well understood need for “higher proof of security-worthiness.” Also, smart cards generally have a smaller code footprint, fewer interfaces that are well-defined and thus they lend themselves fairly well to more in-depth, higher assurance validation. Indeed, the smart card industry – in a foreshadowing and/or inspiration of CC community Protection Profiles (cPPs), was an early adopter of devising common security requirements and “proof of security claims,” doubtless understanding that all smart card manufacturers - and the financial institutions who are heavy issuers of them - have a vested interest in “shared trustworthiness.” This is a great example of understanding that, to quote Ben Franklin, “We must all hang together or assuredly we shall all hang separately.”

The demand for higher assurance evaluations continues in part because the CC has been so successful. Customers worldwide became accustomed to “EAL4” as the gold standard for most commercial software. “EAL-none”—the direction of new style community Protection Profiles (cPP)—hasn’t captured the imagination of the global marketplace for evaluated software in part because the promoters of “no-EAL is the new EAL4” have not made the necessary business case for why “new is better than old.” An honorable, realistic assessment of “new-style” cPPs would explain what the benefits are of the new approach and what the downsides are as part of making a case that “new is better than old.” Consumers do not necessarily upgrade their TV just because they are told “new is better than old;” they upgrade because they can see a larger screen, clearer picture, and better value for money.

Product Complexity and Evaluations

To the extent security evaluation methodology can be more precise and repeatable, that facilitates more consistent evaluations across the board at a lower evaluation cost. However, there is a big difference between products that were designed to do a small set of core functions, using standard protocols, and products that have a broader swathe of functionality and have far more flexibility as to how that functionality is implemented. This means that it will be impossible to standardize testing across products in some product evaluation categories.

For example, routers use standard Internet protocols (or well-known proprietary protocols) and are relatively well defined in terms of what they do. Therefore, it is far easier to test their security using standardized tests as part of a CC evaluation to, for example, determine attack resistance, correctness of protocol implementation, and so forth. The Network Device Protection Profile (NDPP) is the perfect template for this type of evaluation.

Relational databases, on the other hand, use structured query language (SQL) but that does not mean all SQL syntax in all commercial databases is identical, or that protocols used to connect to the database are all identical, or that common functionality is completely comparable among databases. For example, Oracle was the first relational database to implement commercial row level access control: specifically, by attaching a security policy to a table that causes a rewrite of SQL to enforce additional security constraints. Since Oracle developed (and patented) row level access control, other vendors have implemented similar (but not identical) functionality.

As a result, no set of standard tests can adequately test each vendor’s row level security implementation, any more than you can use the same key on locks made by different manufacturers. Prescriptive (monolithic) testing can work for verifying protocol implementations; it will not work in cases where features are implemented differently. Even worse, prescriptive testing may have the effect of “design by test harness.”

Some national CC schemes have expressed concerns that an evaluation of some classes of products (like databases) will not be “meaningful” because of the size and complexity of these products,[1] or that these products do not lend themselves to repeatable, cross-product (prescriptive) testing. This is true, to a point: it is much easier to do a building inspection of a 1000-square foot or 100-square meter bungalow than of Buckingham Palace. However, given that some of these large, complex products are the core underpinning of many critical systems, does it make sense to ignore them because it’s not “rapid, repeatable and objective” to evaluate even a core part of their functionality? These classes of products are heavily used in the core market sectors the national schemes serve: all the more reason the schemes should not preclude evaluation of them.

Worse, given that customers subject to these CC schemes still want evaluated products, a lack of mutual recognition of these evaluations (thus breaking the CCRA) or negation of the ability to evaluate merely drives costs up. Demand for inefficient and ineffective ad hoc security assurances continues to increase and will explode if vendors are precluded from evaluating entire classes of products that are widely-used and highly security relevant. No national scheme, despite good intentions, can successfully control its national marketplace, or the global marketplace for information technology.

Innovation

One of the downsides of rapid, basic, vanilla evaluations is that it stifles the uptake of innovative security features in a customer base that has a lot to protect. Most security-aware customers (like defense and intelligence customers) want new and innovative approaches to security to support their mission. They also want the new innovations vetted properly (via a CC evaluation).

Typically, a community Protection Profile (cPP) defines the set of minimum security functions that a product in category X does. Add-ons can in theory be done via an extended package (EP) – if the community agrees to it and the schemes allow it. The vendor and customer community should encourage the ability to evaluate innovative solutions through an EP, as long as the EP does not specify a particular approach to a threat to the exclusion of other ways to address the threat. This would continue to advance the state of the security art in particular product categories without waiting until absolutely everyone has Security Feature Y. It’s almost always a good thing to build a better mousetrap: there are always more mice to fend off. Rapid adoption of EPs would enable security-aware customers, many of whom are required to use evaluated products, to adopt new features readily, without waiting for:

a) every vendor to have a solution addressing that problem (especially since some vendors may never develop similar functionality)

b) the cPP to have been modified, and

c) all vendors to have evaluated against the new cPP (that includes the new security feature)

Given the increasing focus of governments on improvements to security (in some cases by legislation), national schemes should be the first in line to support “faster innovation/faster evaluation,” to support the customer base they are purportedly serving.

Last but really first, in the absence of the ability to rapidly evaluate new, innovative security features, customers who would most benefit from using those features may be unable or unwilling to use them, or may only use them at the expense of “one-off” assurance validation. Is it really in anyone’s interest to ask vendors to do repeated one-off assurance fire-drills for multiple system integrators?

Conclusion

The Common Criteria – and in particular, the Common Criteria recognition – form a valuable, proven foundation for assurance in a digital world that is increasingly in need of it. That strong foundation can nonetheless be strengthened by:

1) recognizing and supporting the legitimate need for higher assurance evaluations in some classes of product

2) enabling faster innovation in security and the ability to evaluate it via EPs

3) continuing to evaluate core products that have historically had and continue to have broad usage and market demand (e.g., databases and operating systems)

4) embracing, where apropos, repeatable testing and validation, while recognizing the limitations thereof that apply in some cases to entire classes of products and ensuring that such testing is not unnecessarily prescriptive.

Common Criteria and the Future of Security Evaluations

Thu, 2016-10-20 08:00

For years, I (and many others) have recommended that customers demand more of their information technology suppliers in terms of security assurance – that is, proof that security is “built in” and not “bolted on,” that security is “part of” the product or service developed and can be assessed in a meaningful way. While many customers are focused on one kind of assurance – the degree to which a product is free from security vulnerabilities – it is extremely important to know the degree to which a product was designed to meet specific security threats (and how well it does that). These are two distinct approaches to security that are quite complementary and a point that should increasingly be of value for all customers. The good news is that many IT customers – whether of on-premises products or cloud services - are asking for more “proof of assurance,” and many vendors are paying more attention. Great! At the same time, sadly, a core international standard for assurance: the Common Criteria (CC) (ISO 15408), is at risk.

The Common Criteria allows you to evaluate your IT products via an independent lab (certified by the national “scheme” in which the lab is domiciled). Seven levels of assurance are defined – generally, the higher the evaluation assurance level (EAL), the more “proof” you have to provide that your product 1) addresses specific (named) security threats 2) via specific (named) technical remedies to those threats. Over the past few years, CC experts have packaged technology-specific security threats, objectives, functions and assurance requirements into “Protection Profiles” that have a pre-defined assurance level. The best part of the CC is the CC Recognition Arrangement (CCRA), the benefit of which is that a CC security evaluation done in one country (subject to some limits) is recognized in multiple other countries (27, at present). The benefit to customers is that they can have a baseline level of confidence in a product they buy because an independent entity has looked at/validated a set of security claims about that product.

Unfortunately, the CC in danger of losing this key benefit of mutual recognition. The main tension is between countries that want fast, cookie cutter, “one assurance size fits all” evaluations, and those that want (for at least some classes of products) higher levels of assurance. These tensions threaten to shatter the CCRA, with the risk of an “every country for itself,” “every market sector for itself” or worse, “every customer for itself” attempt to impose inconsistent assurance requirements on vendors that sell products and services in the global marketplace. Customers will not be well-served if there is no standardized and widely-recognized starting point for a conversation about product assurance.

The uncertainty about the future of the CC creates opportunity for new, potentially expensive and unproven assurance validation approaches. Every Tom, Dick, and Harriet is jumping on the assurance bandwagon, whether it is developing a new assurance methodology (that the promoters hope will be adopted as a standard, although it’s hardly a standard if one company “owns” the methodology), or lobbying for the use of one proprietary scanning tool or another (noting that none of the tools that analyze code are themselves certified for accuracy and cost-efficiency, nor are the operators of these tools). Nature abhors a vacuum: if the CCRA fractures, there are multiple entities ready to promote their assurance solutions – which may or may not work. (Note: I freely admit that a current weakness of the CC is that, while vulnerability analysis is part of a CC evaluation, it’s not all that one would want. A needed improvement would be a mechanism that ensures that vendors use a combination of tools to more comprehensively attempt to find security vulnerabilities that can weaken security mechanisms and have a risk-based program for triaging and fixing them. Validating that vendors are doing their own tire-kicking – and fixing holes in the tires before the cars leave the factory – would be a positive change.)

Why does this threat of CC balkanization matter? First of all, testing the exact same product or service 27 times won’t in all likelihood lead to a 27-fold security improvement, especially when the cost of the testing is born by the same entity over and over (the vendor). Worse, since the resources (time, money, and people) that would be used to improve actual security are assigned to jumping through the same hoop 27 times, we may paradoxically end up with worse security. We may also end up with worse security to the extent that there will be less incentive for the labs that do CC evaluations to pursue excellence and cost efficiency in testing if they have less competition (for example, from labs in other countries, as is the case under the CCRA) and they are handed a captive marketplace via country-specific evaluation schemes.

Second, whatever the shortcomings of the CC, it is a strong, broadly-adopted foundation for security that to-date has the support of multiple stakeholders. While it may be improved upon, it is nonetheless better to do one thing in one market that benefits and is accepted in 26 other markets than to do 27 or more expensive testing iterations that will not lead to a 27-fold improvement in security. This is especially true in categories of products that some national schemes have deemed “too complex to evaluate meaningfully.” The alternative clearly isn't per-country testing or per-customer testing, because it is in nobody's interests and not feasible for vendors to do repeated one-off assurance fire-drills for multiple system integrators. Even if the CC is “not sufficient” for all types of testing for all products, it is still a reputable and strong baseline to build upon.

Demand for Higher Assurance

In part, the continuing demand for higher assurance CC evaluations is due to the nature of some of the products: smart cards, for example, are often used for payment systems, where there is a well understood need for “higher proof of security-worthiness.” Also, smart cards generally have a smaller code footprint, fewer interfaces that are well-defined and thus they lend themselves fairly well to more in-depth, higher assurance validation. Indeed, the smart card industry – in a foreshadowing and/or inspiration of CC community Protection Profiles (cPPs), was an early adopter of devising common security requirements and “proof of security claims,” doubtless understanding that all smart card manufacturers - and the financial institutions who are heavy issuers of them - have a vested interest in “shared trustworthiness.” This is a great example of understanding that, to quote Ben Franklin, “We must all hang together or assuredly we shall all hang separately.”

The demand for higher assurance evaluations continues in part because the CC has been so successful. Customers worldwide became accustomed to “EAL4” as the gold standard for most commercial software. “EAL-none”—the direction of new style community Protection Profiles (cPP)—hasn’t captured the imagination of the global marketplace for evaluated software in part because the promoters of “no-EAL is the new EAL4” have not made the necessary business case for why “new is better than old.” An honorable, realistic assessment of “new-style” cPPs would explain what the benefits are of the new approach and what the downsides are as part of making a case that “new is better than old.” Consumers do not necessarily upgrade their TV just because they are told “new is better than old;” they upgrade because they can see a larger screen, clearer picture, and better value for money.

Product Complexity and Evaluations

To the extent security evaluation methodology can be more precise and repeatable, that facilitates more consistent evaluations across the board at a lower evaluation cost. However, there is a big difference between products that were designed to do a small set of core functions, using standard protocols, and products that have a broader swathe of functionality and have far more flexibility as to how that functionality is implemented. This means that it will be impossible to standardize testing across products in some product evaluation categories.

For example, routers use standard Internet protocols (or well-known proprietary protocols) and are relatively well defined in terms of what they do. Therefore, it is far easier to test their security using standardized tests as part of a CC evaluation to, for example, determine attack resistance, correctness of protocol implementation, and so forth. The Network Device Protection Profile (NDPP) is the perfect template for this type of evaluation.

Relational databases, on the other hand, use structured query language (SQL) but that does not mean all SQL syntax in all commercial databases is identical, or that protocols used to connect to the database are all identical, or that common functionality is completely comparable among databases. For example, Oracle was the first relational database to implement commercial row level access control: specifically, by attaching a security policy to a table that causes a rewrite of SQL to enforce additional security constraints. Since Oracle developed (and patented) row level access control, other vendors have implemented similar (but not identical) functionality.

As a result, no set of standard tests can adequately test each vendor’s row level security implementation, any more than you can use the same key on locks made by different manufacturers. Prescriptive (monolithic) testing can work for verifying protocol implementations; it will not work in cases where features are implemented differently. Even worse, prescriptive testing may have the effect of “design by test harness.”

Some national CC schemes have expressed concerns that an evaluation of some classes of products (like databases) will not be “meaningful” because of the size and complexity of these products [1], or that these products do not lend themselves to repeatable, cross-product (prescriptive) testing. This is true, to a point: it is much easier to do a building inspection of a 1000-square foot or 100-square meter bungalow than of Buckingham Palace. However, given that some of these large, complex products are the core underpinning of many critical systems, does it make sense to ignore them because it’s not “rapid, repeatable and objective” to evaluate even a core part of their functionality? These classes of products are heavily used in the core market sectors the national schemes serve: all the more reason the schemes should not preclude evaluation of them.

Worse, given that customers subject to these CC schemes still want evaluated products, a lack of mutual recognition of these evaluations (thus breaking the CCRA) or negation of the ability to evaluate merely drives costs up. Demand for inefficient and ineffective ad hoc security assurances continues to increase and will explode if vendors are precluded from evaluating entire classes of products that are widely-used and highly security relevant. No national scheme, despite good intentions, can successfully control its national marketplace, or the global marketplace for information technology.

Innovation

One of the downsides of rapid, basic, vanilla evaluations is that it stifles the uptake of innovative security features in a customer base that has a lot to protect. Most security-aware customers (like defense and intelligence customers) want new and innovative approaches to security to support their mission. They also want the new innovations vetted properly (via a CC evaluation).

Typically, a community Protection Profile (cPP) defines the set of minimum security functions that a product in category X does. Add-ons can in theory be done via an extended package (EP) – if the community agrees to it and the schemes allow it. The vendor and customer community should encourage the ability to evaluate innovative solutions through an EP, as long as the EP does not specify a particular approach to a threat to the exclusion of other ways to address the threat. This would continue to advance the state of the security art in particular product categories without waiting until absolutely everyone has Security Feature Y. It’s almost always a good thing to build a better mousetrap: there are always more mice to fend off. Rapid adoption of EPs would enable security-aware customers, many of whom are required to use evaluated products, to adopt new features readily, without waiting for:

a) every vendor to have a solution addressing that problem (especially since some vendors may never develop similar functionality)

b) the cPP to have been modified, and

c) all vendors to have evaluated against the new cPP (that includes the new security feature)

Given the increasing focus of governments on improvements to security (in some cases by legislation), national schemes should be the first in line to support “faster innovation/faster evaluation,” to support the customer base they are purportedly serving. Last but really first, in the absence of the ability to rapidly evaluate new, innovative security features, customers who would most benefit from using those features may be unable or unwilling to use them, or may only use them at the expense of “one-off” assurance validation. Is it really in anyone’s interest to ask vendors to do repeated one-off assurance fire-drills for multiple system integrators?

Conclusion

The Common Criteria – and in particular, the Common Criteria recognition – form a valuable, proven foundation for assurance in a digital world that is increasingly in need of it. That strong foundation can nonetheless be strengthened by:

1) recognizing and supporting the legitimate need for higher assurance evaluations in some classes of product

2) enabling faster innovation in security and the ability to evaluate it

3) continuing to evaluate core products that have historically had and continue to have broad usage and market demand (e.g., databases and operating systems)

4) embracing, where apropos, repeatable testing and validation, while recognizing the limitations thereof that apply in some cases to entire classes of products and ensuring that such testing is not unnecessarily prescriptive.

[1] https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/DBMS%20Position%20Statement.pdf

October 2016 Critical Patch Update Released

Tue, 2016-10-18 14:59

Oracle today released the October2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide rangeof product families including: Oracle Database Server, Oracle E-Business Suite,Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products,Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied assoon as possible. A summary and analysis of this Critical Patch Update has beenpublished on MyOracle Support (Doc ID 2193091.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html

My Oracle Support Note 2193091.11 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2193091.1 (MOS account required).

October 2016 Critical Patch Update Released

Tue, 2016-10-18 14:59

Oracle today released the October 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (Doc ID 2193091.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html

My Oracle Support Note 2193091.11 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2193091.1 (MOS account required).

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0in; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

October 2016 Critical Patch Update Released

Tue, 2016-10-18 08:00

Oracle today released the October 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (Doc ID 2193091.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html

My Oracle Support Note 2193091.11 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2193091.1 (MOS account required).

Unmasking Hackers with User Behavior Analytics

Tue, 2016-09-06 08:00

Many people keep sensitive documents in cloud storage services and the latest breach shows that hackers are focusing on online storage cloud services more frequently. This opens the door to huge vulnerabilities if employees are storing sensitive enterprise information in the cloud. From a preventative perspective, security personnel should review their security measures for the following:

  1. Require multi-factor authentication to access the application
  2. Enforce password strength and complexity requirements
  3. Require and enforce frequent password resets for employees

But manual processes and policies are not enough. At minimum, enterprises should look at automating the enforcement of these policies. For example, you may require multi-factor authentication, but how do you ensure that it's required at all times? A cloud access security broker (CASB) continuously monitors configurations to alert security personnel when changes are made, and automatically creates incident tickets to revert security configurations back to the default setting.   How can enterprises prevent further damage if their employees' credentials were compromised in this hack? We recommend utilizing user behavior analytics (UBA) to look for anomalous activity in an account. UBA uses advanced machine learning techniques to create a baseline for normal behavior for each user. If a hacker is accessing an employee's account using stolen credentials, UBA will flag a number of indicators that this access deviates from the normal behavior of a legitimate user.   Palerra LORIC is a cloud access security broker (CASB) that supports cloud storage services. Here's a few indicators LORIC can use to unmask a potential hacker with stolen credentials:

  1. Flag a login from an unusual IP address or geographic location
  2. Detect a spike in number of file downloads compared to normal user activity
  3. Detect logins outside of normal access hours for the user
  4. Detect anomalous file sharing or file previewing activities

The ability to gauge legitimate access and activities becomes even more important when you consider that many people use the same password for multiple applications. Instead of just protecting a single online storage cloud service, UBA helps the enterprise protect any cloud environment that could be accessed using the stolen passwords.

If you're concerned that hackers may access your cloud storage environment using stolen employee credentials, you should take preventative and remedial action. Adding a cloud security automation tool help prevents a breach by enforcing password best practices, and helps prevents additional damage after a breach by unmasking hackers posing as legitimate users by flagging anomalous activity.

July 2016 Critical Patch Update Released

Tue, 2016-07-19 14:51

Oracle today released the July2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide rangeof product families including: Oracle Database Server, Oracle E-Business Suite,Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products,Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied assoon as possible. A summary and analysis of this Critical Patch Update has beenpublished on My Oracle Support (MOS Note 2161607.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html

My Oracle Support Note 2161607.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2161607.1 (MOS account required).

July 2016 Critical Patch Update Released

Tue, 2016-07-19 14:51

Oracle today released the July 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2161607.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html

My Oracle Support Note 2161607.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2161607.1 (MOS account required).

July 2016 Critical Patch Update Released

Tue, 2016-07-19 08:00

Oracle today released the July 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Industry Applications, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2161607.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html

My Oracle Support Note 2161607.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2161607.1 (MOS account required).

Why Monitoring Alone is Not Enough in Cloud Security

Tue, 2016-07-19 07:00

Comprehensive threat intelligence is key for ensuring accuracy and maximize effectiveness of automated security solutions. Monitoring alone is not enough to correctly identify and remediate a breach. And, while human supervision will always be part of the security equation, the overwhelming amount of data accessible from cloud providers makes it impossible for security personnel to identify and remediate all threats. Here are three ways organizations can use threat intelligence to enhance their current security measures and go beyond simply monitoring their cloud environment:

  1. Require multi-factor authentication: Multi-factor authentication gives the end user more visibility into potential attacks on their account, and they'll change their password before a breach occurs. But how do you ensure that multi-factor authentication is required at all times? A cloud security automation platform continuously monitors security configurations to alert security personnel when changes are made, and automatically creates incident tickets to revert security configurations back to the default setting.

  2. Configure password policies and strength to maintain password integrity: Many people use the same password to log into multiple service providers, and most do not regularly update their passwords. Organizations should configure password policies to ensure passwords expire every 90 days, and cap the number of recycled passwords that can be used. An automated security system enforces password strength requirements to reduce the likelihood of a breach. These systems can flag changes to the password settings, which might indicate an insider threat or hacker access to your system.

  3. Utilize comprehensive threat intelligence: In order to focus on the most credible threats, your security team needs clear, actionable information. Using key security indicators in your automation program can consolidate and correlate data to provide instant insight into the security posture of your cloud services. By setting up custom notifications for likely threat scenarios, security teams can focus on the most immediate threats instead of chasing down potentially useless information.

It's not enough to simply monitor cloud services or have a "set it and forget it" mindset about security configurations. Instead, companies must leverage cloud security automation to bring the most immediate and credible threats to the attention of the security team.

Can a CASB Protect You From the Treacherous 12? - Part 4: CASBs and the Treacherous 7 through 12

Thu, 2016-04-21 07:00

Welcome to the fourth in a four-part series on how Cloud Access Security Brokers (CASBs) can help protect your organization from the top twelve threats to cloud computing in 2016. If you want to read the first three blogs, their links are provided below.  

This blog series examines whether a CASB can protect your organization from the top cloud computing threats identified by a Cloud Security Alliance (CSA) working group. The four-part series includes:

- Part 1: CASB 101
- Part 2: CASBs and Threat Detection
- Part 3: CASBs and the Treacherous 1- 6
- Part 4: CASBs and the Treacherous 7-12

CASBs and the Treacherous 7 through 12

The final 6 of the "Treacherous 12" threats that the CSA working group identified are:

7. Advanced Persistent Threats (APTs)
8. Data loss
9. Insufficient due diligence
10. Abuse and nefarious use of cloud services
11. Denial of Service (DoS)
12. Shared technology issues

Here is a definition and an anecdote for each of these threats, along with an assessment of whether a Cloud Access Security Broker (CASB) like Palerra can help protect against it.

7. Advanced Persistent Threats (APTs)
An APT is a parasitical form of cyberattack that infiltrates systems and establishes a foothold in the computing infrastructure. Once the foothold is in place, the perpetrator can smuggle data and intellectual property. 

A CASB can help with APT attacks. A CASB can help detect anomalies in inbound and outbound data to identify data exfiltration, which further enables you to discover that a network is the target of an attack. 

8. Data loss
Data loss can be due to malicious attacks, accidental deletion by the cloud service provider, or a physical catastrophe such as a fire or earthquake.

A CASB is not the solution in this case. Cloud service providers should take measures to back up data according to best practices in business continuity and disaster recovery. Consumers of these services should review the service provider's data loss provisions. 

9. Insufficient due diligence
When a business is under pressure to leverage the benefits of the cloud, the selection process for adopting cloud technologies and choosing cloud service providers can get rushed and proper due diligence can be skipped. When that occurs, organizations are exposing a myriad of commercial, financial, technical, legal, and compliance risks. 

A CASB is not the solution in this case. Executives need to develop a good roadmap and checklist for due diligence when evaluating technologies and cloud service providers. A CASB can help in that process, but the responsibility is with the executives. 

10. Abuse and nefarious use of cloud services
Poorly secured cloud service deployments, free cloud service trials, and account sign-ups that exploit fraudulent payment instruments expose all cloud computing models (including IaaS, Paas, and SaaS). 

A CASB can help monitor identity as a service (IaaS) workloads and software as a service (SaaS) access patterns to better detect suspicious activity such as abnormal launches and terminations of compute instances and abnormal user access patterns.

11. Denial of Service (DoS)
A DoS attack is meant to prevent users of a service from being able to access their data or applications. DoS attacks also flood the cloud service provider with access requests, with the intent of disrupting the service.

A CASB is not the solution in this case. Cloud providers hold the responsibility for taking appropriate precautions to mitigate the impact of DoS attacks.

12. Shared technology issues
Cloud service providers deliver scalable services by sharing infrastructure, platforms, or applications. Because of this shared architecture, one vulnerability or misconfiguration can lead to a compromise across IaaS, PaaS, and SaaS. For example, the VENOM vulnerability allowed attackers to compromise any virtualized platform, which opened millions of virtual machines to attack.

A CASB can help with monitoring of compute, storage, network, and application resources, as well as user security enforcement and cloud service configurations, whether the service model is IaaS, PaaS, or SaaS. However, not all CASBs cover all areas, so be sure that you are working with one that does.

This is the final blog post in the four-part series. For additional information, check out our white paper, "Can a CASB Protect You from the 2016 Treacherous 12?". Or if you prefer an abbreviated format, check out our infographic on the same topic.

April 2016 Critical Patch Update Released

Tue, 2016-04-19 15:02

Oracle today released the April 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2126904.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html

My Oracle Support Note 2126904.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2126904.1 (MOS account required).

April 2016 Critical Patch Update Released

Tue, 2016-04-19 15:02

Oracle today released the April 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2126904.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html

My Oracle Support Note 2126904.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2126904.1 (MOS account required).

April 2016 Critical Patch Update Released

Tue, 2016-04-19 07:00

Oracle today released the April 2016 Critical Patch Update.

This Critical Patch Update provides fixes for a wide range of product families including: Oracle Database Server, Oracle E-Business Suite, Oracle Fusion Middleware, Oracle Sun Products, Oracle Java SE, and Oracle MySQL.

Oracle recommends this Critical Patch Update be applied as soon as possible. A summary and analysis of this Critical Patch Update has been published on My Oracle Support (MOS Note 2126904.1)

For More Information:

The Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html

My Oracle Support Note 2126904.1 is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2126904.1 (MOS account required).

Security Alert CVE-2016-0636 Released

Wed, 2016-03-23 14:46

Oracle released SecurityAlert CVE-2016-0636 to address a vulnerability affecting Java SE in webbrowsers on desktops. This vulnerabilityhas received a CVSS Base Score of 9.3 and is remotely exploitable withoutauthentication. A successfulexploitation of this vulnerability would typically require an unsuspecting userrunning an affected version of Java SE to visit a malicious web site.

Oracle recommends customers apply this Security Alert assoon as possible. Oracle recommends that Java home users visit Java.com to ensure that they are running themost recent version of Java SE and that all older versions of Java SE have beencompletely removed. Oracle further advises against downloading Java from sitesother than Java.com as these sites may be malicious.


For more information:

The Advisory for Security AlertCVE-2016-0636 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0636-2949497.html

Security Alert CVE-2016-0636 Released

Wed, 2016-03-23 14:46

Oracle released Security Alert CVE-2016-0636 to address a vulnerability affecting Java SE in web browsers on desktops. This vulnerability has received a CVSS Base Score of 9.3 and is remotely exploitable without authentication. A successful exploitation of this vulnerability would typically require an unsuspecting user running an affected version of Java SE to visit a malicious web site.

Oracle recommends customers apply this Security Alert as soon as possible. Oracle recommends that Java home users visit Java.com to ensure that they are running the most recent version of Java SE and that all older versions of Java SE have been completely removed. Oracle further advises against downloading Java from sites other than Java.com as these sites may be malicious.


For more information:

The Advisory for Security Alert CVE-2016-0636 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0636-2949497.html

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0in; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Security Alert CVE-2016-0603 Released

Fri, 2016-02-05 14:42

Oracle just released Security Alert CVE-2016-0603 to address a vulnerability that can be exploited when installing Java 6, 7 or 8 on the Windows platform. This vulnerability has received a CVSS Base Score of 7.6.

To be successfully exploited, this vulnerability requires that an unsuspecting user be tricked into visiting a malicious web site and download files to the user's system before installing Java 6, 7 or 8. Though considered relatively complex to exploit, this vulnerability may result, if successfully exploited, in a complete compromise of the unsuspecting user’s system.

Because the exposure exists only during the installation process, users need not upgrade existing Java installations to address the vulnerability. However, Java users who have downloaded any old version of Java prior to 6u113, 7u97 or 8u73, should discard these old downloads and replace them with 6u113, 7u97 or 8u73 or later.

As a reminder, Oracle recommends that Java home users visit Java.com to ensure that they are running the most recent version of Java SE and that all older versions of Java SE have been completely removed. Oracle further advises against downloading Java from sites other than Java.com as these sites may be malicious.

For more information, the advisory for Security Alert CVE-2016-0603 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0603-2874360.html

Security Alert CVE-2016-0603 Released

Fri, 2016-02-05 14:42

Oracle just released Security Alert CVE-2016-0603 to address a vulnerability that can be exploited when installing Java 6, 7 or 8 on the Windows platform. This vulnerability has received a CVSS Base Score of 7.6.

To be successfully exploited, this vulnerability requires that an unsuspecting user be tricked into visiting a malicious web site and download files to the user's system before installing Java 6, 7 or 8. Though considered relatively complex to exploit, this vulnerability may result, if successfully exploited, in a complete compromise of the unsuspecting user’s system.

Because the exposure exists only during the installation process, users need not upgrade existing Java installations to address the vulnerability. However, Java users who have downloaded any old version of Java prior to 6u113, 7u97 or 8u73, should discard these old downloads and replace them with 6u113, 7u97 or 8u73 or later.

As a reminder, Oracle recommends that Java home users visit Java.com to ensure that they are running the most recent version of Java SE and that all older versions of Java SE have been completely removed. Oracle further advises against downloading Java from sites other than Java.com as these sites may be malicious.

For more information, the advisory for Security Alert CVE-2016-0603 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2016-0603-2874360.html

 

January 2016 Critical Patch Update Released

Tue, 2016-01-19 18:11

Oracle today released the January2016 Critical Patch Update.  With this Critical Patch Update release,the CriticalPatch Update program enters its 11th year of existence(the first Critical Patch Update was released in January 2005).  As areminder, Critical Patch Updates are currently released 4 times a year, on aschedule announced a year in advance.  Oracle recommends that customersapply this Critical Patch Update as soon as possible.

TheJanuary2016 Critical Patch Update provides fixes for a wide range of productfamilies; including: 

  • Oracle Database
    • None of these database vulnerabilities are remotely exploitable without authentication. 
  • Java SE vulnerabilities
    • Oracle strongly recommends that Java home users visit the java.com web site, to ensure that they are using the most recent version of Java and are advised to remove obsolete Java SE versions from their computers if they are not absolutely needed.
  • Oracle E-Business Suite.
    • Oracle’s ongoing assurance effort with E-Business Suite helps remediate security issues and is intended to help enhance the overall security posture provided by E-Business Suite.

Oracletakes security seriously, and stronglyencourages customers to keep up with newer releases in order tobenefit from Oracle’s ongoing security assurance effort.  

Formore information:

TheJanuary 2016 Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html

TheOracle Software Security Assurance web site is located at https://www.oracle.com/support/assurance/index.html.

OracleApplications Lifetime Support Policy is located at http://www.oracle.com/us/support/library/lifetime-support-applications-069216.pdf.

January 2016 Critical Patch Update Released

Tue, 2016-01-19 18:11

Oracle today released the January 2016 Critical Patch Update.  With this Critical Patch Update release, the Critical Patch Update program enters its 11th year of existence (the first Critical Patch Update was released in January 2005).  As a reminder, Critical Patch Updates are currently released 4 times a year, on a schedule announced a year in advance.  Oracle recommends that customers apply this Critical Patch Update as soon as possible.

The January 2016 Critical Patch Update provides fixes for a wide range of product families; including: 

  • Oracle Database
    • None of these database vulnerabilities are remotely exploitable without authentication. 
  • Java SE vulnerabilities
    • Oracle strongly recommends that Java home users visit the java.com web site, to ensure that they are using the most recent version of Java and are advised to remove obsolete Java SE versions from their computers if they are not absolutely needed.
  • Oracle E-Business Suite.
    • Oracle’s ongoing assurance effort with E-Business Suite helps remediate security issues and is intended to help enhance the overall security posture provided by E-Business Suite.

Oracle takes security seriously, and strongly encourages customers to keep up with newer releases in order to benefit from Oracle’s ongoing security assurance effort.  

For more information:

The January 2016 Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html

The Oracle Software Security Assurance web site is located at https://www.oracle.com/support/assurance/index.html.

Oracle Applications Lifetime Support Policy is located at http://www.oracle.com/us/support/library/lifetime-support-applications-069216.pdf.

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0in; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Pages