Should DevOps be DevOpsSec

Neil MacDonald, a Gartner Fellow, published a blog on Security in DevOps. I like his comment on a secure system, 

A well-designed, developed and managed system is the foundation of a secure system. 

He has published a research note on DevOpsSec: Creating the Agile Triangle. You can find his original blog here.

DevOps seeks to bridge the development and operations divide through the establishment of a culture of trust and shared interest among individuals in these previously siloed organizations. However, this vision is incomplete without the incorporation of information security, which represents yet another silo in IT. Breakdowns in communications and processes across development, operations and security are the root cause of the vast majority of critical system downtime, including downtime caused by breaches in security. For example, Gartner research shows that 75% of successful attacks occur against previously known vulnerabilities for which a patch or secure configuration standard was already available (actually, this used to be about 90%, but advanced and targeted attacks have changed the equation).

Conventional wisdom believes the agile nature of the DevOps vision is fundamentally at odds with the historically static and cumbersome nature of information security. I disagree. I believe that security can support a unified vision of DevOpsSec, but to do this, information security must change in multiple ways including security infrastructure becoming more adaptive andprogrammable and making information security representation an integral part of DevOpsSec teams from the genesis of new applications and services.

I’ve just published a research note for clients DevOpsSec: Creating the Agile Triangle that makes the argument for DevOpsSec and outlines the major areas of change for information security to support a unified DevOpsSec vision. My colleague, Cameron Haight, from the IT Operations side of Gartner research joined me on the research note. He has pioneered much of the research on DevOps for Gartner and increasingly he is being asked how DevOps can be adopted without sacrificing security. Increasingly, I am being asked how to rationalize the agile nature of DevOps with the need for security testing. Together, we teamed up to deliver the first in a series of research notes on how to deliver DevOpsSec.

Development, operations and security are fundamentally intertwined. A well-designed, developed and managed system is the foundation of a secure system. DevOps must evolve to a new vision of DevOpsSec that balances the need for speed and agility of enterprise IT capabilities with the enterprise need to protect critical assets, applications and services.

Red Hat JBoss Enterprise Application Server (EAP) and the Payment Card Industry (PCI) Data Security Standard

Our guest blogger this week is Albert T. Wong ([email protected])

The Payment Card Industry (PCI) Data Security Standard (DSS) is a proprietary information security standard for organizations that handle branded credit cards from the major card schemes including American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International. The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council.

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

The PCI DSS Version 3.1 standard (released in 2015) lists twelve (12) requirements which retailers, online merchants, credit data processors, and other payment related businesses must implement to help protect cardholders and their data. The requirements include technology controls (such as data encryption, virus protection, end-user access control and activity monitoring) as well as required procedures.

Most of the requirements focus on site security and encryption, but some of them apply to securing your applications. The JBoss Enterprise Application Server (EAP) team has produced this technical overview document to assist you in understanding the PCI requirements, determining which requirements apply to JBoss Enterprise Application Server (EAP), and how JBoss Enterprise Application Server (EAP) implements the applicable requirements.

The use of JBoss Enterprise Application Server (EAP) in your electronic commerce site, even if installed and configured correctly, does not guarantee that your site will be PCI compliant. The purpose of this document is to describe the relationship between JBoss Enterprise Application Server (EAP) and the PCI Data Security Standard requirements, not about an entire operating environment. PCI compliance can also impose requirements on other components of your site involved in the storage, processing, or transmission of cardholder data, including firewalls, routers, Web servers, Operating Systems, databases and the web application. PCI compliance remains solely the responsibility of the merchant.

For your reference, here is the outline of the standard:

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs.

Requirement 6: Develop and maintain secure systems and applications.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know.

Requirement 8: Identify and authenticate access to system components.

Requirement 9: Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data.

Requirement 11: Regularly test security systems and processes.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel.

Where to find information about the Payment Card Industry (PCI) Data Security Standard

Payment Card Industry Data Security Standard: https://www.pcisecuritystandards.org/index.shtml

JBoss Enterprise Application Server (EAP) and PCI compliance

The PCI Data Security Standard (DSS) addresses far more than the security of your JBoss Enterprise Application Server (EAP) application. It covers broad security requirements such as virus protection, and restricting physical access to cardholder data.

It is important to recognize the scope of the requirements, and which of them are related to JBoss Enterprise Application Server (EAP).

Control Objective	Relationship
1: Install and maintain a firewall configuration to protect cardholder data.	Related only to PCI DSS
2: Do not use vendor-supplied defaults for system passwords and other security parameters.	Focus area
3: Protect stored cardholder data.	Related only to PCI DSS
4: Encrypt transmission of cardholder data across open, public networks.	Focus area
5: Protect all systems against malware and regularly update anti-virus software or programs.	Related only to PCI DSS
6: Develop and maintain secure systems and applications.	Related only to PCI DSS
7: Restrict access to cardholder data by business need to know.	Focus area
8: Identify and authenticate access to system components.	Focus area
9: Restrict physical access to cardholder data.	Related only to PCI DSS
10: Track and monitor all access to network resources and cardholder data.	Focus area
11: Regularly test security systems and processes.	Related only to PCI DSS
12: Maintain a policy that addresses information security for all personnel.	Related only to PCI DSS

PCI Security Standards Council Notices: Legal Terms and Conditions

Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that payment application that was reviewed by a PA-QSA and subsequently accepted by PCI SSC (the "Accepted Version"). If any aspect of a payment application or version thereof is different from that which was reviewed by the PA-QSA and accepted by PCI SSC – even if the different payment application or version (the "Alternate Version") conforms to the basic product description of the Accepted Version – then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as accepted by PCI SSC.

No vendor or other third party may refer to a payment application as "PCI Approved" or "PCI SSC Approved", and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or payment applications, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a PA-DSS letter of acceptance provided by PCI SSC. All other references to PCI SSC's approval or acceptance of a payment application or version thereof are strictly and actively prohibited by PCI SSC.

When granted, PCI SSC acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC's goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the payment application vendor or the functionality, quality, or performance of the payment application or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement, all of which are expressly disclaimed by PCI SSC. All rights and remedies regarding products and services that have received acceptance from PCI SSC, shall be provided by the party providing such products or services, and not by PCI SSC or any payment brands.

Addressing the PCI Data Security Standard within JBoss Enterprise Application Server (EAP)

The following topics deal with each of the detailed requirements that pertain to JBoss Enterprise Application Server (EAP). Some of the requirements are directly related to the JBoss Enterprise Application Server (EAP) software package. Other requirements are unrelated, or indirectly relate to the JBoss Enterprise Application Server (EAP) software package. For example, indirect requirements can affect your use of the operating system security features to secure JBoss Enterprise Application Server (EAP) files.

PCI Assessment Services for JBoss Enterprise Application Server (EAP)

There is much more to navigating the PCI standard and the certification procedure than simply installing JBoss Enterprise Application Server (EAP) and making the adjustments we have outlined in the preceding sections. There are significant portions of the standard that, although it applies to your site, does not apply to the software application. To assist you in completely addressing these parts of the standard, Red Hat consulting can assist your site in becoming PCI compliant.

Addressing the PCI Data Security Standard within JBoss Enterprise Application Server (EAP)

The following topics deal with each of the detailed requirements that pertain to JBoss Enterprise Application Server (EAP). Some of the requirements are directly related to the JBoss Enterprise Application Server (EAP) software package. Other requirements are unrelated, or indirectly relate to the JBoss Enterprise Application Server (EAP) software package. For example, indirect requirements can affect your use of the operating system security features to secure JBoss Enterprise Application Server (EAP) files.

For several of the requirements that are related only to PCI compliance (and not to JBoss Enterprise Application Server (EAP)) you are referred directly to the PCI DSS for details. Ensure that you keep up with the rapid pace of changing security requirements.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Many parts of requirement 1 such as your wireless network or router setup do not directly relate to JBoss Enterprise Application Server (EAP), but the requirements that relate to your site topology are extremely important. You must construct your JBoss Enterprise Application Server (EAP) site so that you never store cardholder data on internet-accessible systems. Additionally, JBoss Enterprise Application Server (EAP) sites should always use firewalls to separate themselves from the internet, internal networks, and any other system that is accessible to the internet. Ensure that you implement JBoss Enterprise Application Server (EAP) in a 3–tier configuration using the JBoss EAP Reference Architecture (http://www.redhat.com/en/resources/jboss-eap-6-clustering)

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Read the JBoss EAP Security Guide for details on changing the system password and system hardening.

Requirement 3: Protect stored cardholder data

Beyond the scope of JBoss EAP.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Disable SSLv2 and older security encryption on your web server.

Enable Federal Information Processing Standards publication 140-2 (FIPS 140-2) security standard.

Enable National Institute of Standards and Technology (NIST) Special Publications 800-131A (SP 800-131A) security standard.

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Although antivirus software is outside the scope of JBoss Enterprise Application Server (EAP), protecting your servers and network from malicious software should always be a priority for a responsible network administrator.

Requirement 6: Develop and maintain secure systems and applications

Ensure that your store error pages do not display stack traces, either visibly, or in the page source.

As your business needs change, you or your business partners might customize your JBoss Enterprise Application Server (EAP) site. As you do so, you must ensure that the customizations do not compromise your site security. Ensure that your developers understand the requirement to develop secure systems by referring to the PA-DSS and PCI-DSS.

Please also monitor the top 10 list of security threats by the Open Web Appliction Security Project (OWASP)

Requirement 7: Restrict access to cardholder data by business need to know

Read the JBoss EAP Security Guide for details on access control lists.

Requirement 8: Identify and authenticate access to system components
Read the JBoss EAP Security Guide for details on default account policies.

Requirement 9: Restrict physical access to cardholder data

Beyond the scope of JBoss EAP.

Requirement 10: Track and monitor all access to network resources and cardholder data

Ensure that the correct level of logging is enabled. Please see JBoss EAP documentation for more details.

Requirement 11: Regularly test security systems and processes

Beyond the scope of JBoss EAP.

Requirement 12: Maintain a policy that addresses information security for all personnel

Beyond the scope of JBoss EAP.

Red Hat JBoss Enterprise Application Platform 6.2 Achieves Highest Level Common Criteria Certification

JBoss Enterprise Application Platform 6.2 has been awarded the Common Criteria Certification at

Evaluation Assurance Level (EAL) 4+ which is the highest level of assurance for a commercial middleware platform.  

Achieving the Common Criteria Certification for JBoss Enterprise Application Platform 6.2 supports Red Hat's reputation as an industry leader in technology and showcases the company's ongoing commitment to security. In 2012, JBoss Enterprise Application Platform 5.1.0 and 5.1.1 also achieved Common Criteria certification at the EAL4+ assurance level.

The Common Criteria is an internationally recognized set of standards used by the federal government and organizations to assess the security and assurance of technology products. EAL categorizes the depth and rigor of the evaluation, and EAL4+ assures consumers that the software has been methodically designed, tested, and reviewed to meet the evaluation criteria.

As with past Common Criteria certifications, Red Hat worked with atsec information security, a government accredited laboratory in the United States and Germany. atsec tested and validated the security, performance and reliability of the solution against the Common Criteria Standard for Information Security Evaluation (ISO/IEC 15408) at EAL4+.

You can find the Certificate, Security Target and Certification Report at:

https://www.bsi.bund.de/SharedDocs/Zertifikate/CC/Serveranwendungen_Application_Server/0909.html

You can also find more information on Common Criteria at:

https://www.commoncriteriaportal.org

This new certification underlines Red Hat’s commitment to providing the highest possible level of security for our products and adds to existing certifications and accreditations for other middleware and infrastructure products :

http://www.redhat.com/en/technologies/industries/government/standards

Further details in the press-release here :

http://investors.redhat.com/releasedetail.cfm?ReleaseID=906717

Security Content Automation Protocol (SCAP) Compliance Checker

The SCAP Compliance Checker (SCC) is a Security Content Automation Protocol (SCAP) validated application developed by Space and Naval Warfare (SPAWAR) Systems Center Atlantic.   Version 4 has been officially released.

Obtaining the Software (DOD)
For Department of Defense (DOD) users with a valid Common Access Card (CAC), the software can be downloaded directly from DISA: http://iase.disa.mil/stigs/scap/index.html then scroll down to "SCAP Tools"

Obtaining the Software (Non-DOD)
For US Government Employees and contractors, the software can be obtained via the Office of Management and Budget (OMB) hosted MAX.omb.gov website. Users will be required to self-activate an account in order to obtain the files.

After registration, the software can be downloaded from:
https://max.omb.gov/community/x/KYRhKg

Alternate Method
SCC is available for any government employee or contractor to the US government; it is not available to the general public.

If you are unable to download SCC by one of the 2 primary methods above, the software can be requested by emailing: [email protected] . Please include the following in your request:

1. US Federal agency you are supporting
2. Government POC with .gov or .mil email address or Contract Number

Standards Supported - Platforms Supported:

SCAP Version: 1.0 - Windows XP & Server 2003
OVAL Version: 5.10.1 - Windows Vista & Server 2008
XCCDF Version: 1.1.4  - Windows 7 & Server 2008 R2
CPE Version: 2.2  - Windows 8 & Server 2012
CCE Version: 5.0 - Solaris 10
OCIL Version: 2.0 - Red Hat Enterprise Linux 4 & 5
DOD ARF Version: 0.41  - Debian Linux 5 & 6
Cyberscope Version: 1.0.0 Early Access Release - Mac OS X 10.6, 10.7

Picketlink and Keycloak projects are merging!

Boleslaw Dawidowicz has written a blog with detail regarding Picketlink and Keycloak projects merging.  Check out his blog here and some excerpts are below.   A Knowledge Base article has also been published which is here.

Together with new PicketLink 2.7.0.Final release, we would like to announce that PicketLink and Keycloak projects will be merging their efforts. Code base of both will get unified and new features will be developed in a single place.

As part of this merge all key features of PicketLink will get included into Keycloak. Combining strengths of both projects and providing their communities a single polished and unified security solution. Joining both efforts should enable faster progress on new features which will be beneficial for all users and developers leveraging those solutions.

What you can expect happening during next few months?

• Specific parts of PicketLink codebase being forked and merged into Keycloak. We are starting with PicketLink Federation / SAML. 
• Inclusion or implementation of particular features will get discussed in public on theKeycloak project mailing list. We are looking forward for your participation there as we would like to hear your feedback on changes that we are doing. 
• Web sites for both projects will get slightly changed to reflect new situation.
• Many new cool features coming shortly!

Pedro Igor Silva - PicketLink Project Leader
Bill Burke and Stian Thorgersen - Keycloak Project Leaders
Bolesław Dawidowicz - Security Platform Architect at Red Hat.

One Way and Two Way SSL and TLS

Overview

---

Top to Bottom - Internet Explorer, Firefox, Safari, Chrome, and Opera 

Before going into Endpoint Security with Camel with EAP and Fuse,  I wanted to provide a quick primer on Secure Sockets Layer (SSL).  We will have a quick overview and then discuss 1-way and 2-way SSL.  SSL should be the first step in protecting sensitive data across the network pipe.  It will minimize the man-in-the-middle attacks and eavesdropping.  SSL is the standard security technology for establishing an encrypted link between a web server and a browser.  This makes sure the data passed between the server and browser or server and server remains private and not modified by providing encryption and trust.

Encryption uses a private key/public key pair which ensures that the data can be encrypted by one key but can only be decrypted by the other key pair.   This is referred to as the Public-Key Infrastructure (PKI) Scheme.  The public key is shared while the private key is kept locally.  This is described more in 1 and 2 way SSL below concerning the files and which are stored where.  This can also be extending to server to server communication, in addition to browser to server communication.

Trust is achieved through the use of certificate trust.   Certificate trust can be thought of as a chain that starts with the Certificate Authority (or CA).  A CA is a company or entity that issues SSL Certificates.   Web browsers and  systems come loaded with a list of recognized issuers and that list is kept up to date by automatic updates.   Certificates can also be self-signed for testing.

Benefits of SSL through the CIA Triad

---

I blogged about the CIA Triad Model which is located here,  The SANS institue has an excellent beginners guide to SSL and TLS which also describes the value of SSL/TLS in relation to the CIA Triad.

The C-I-A (Confidentiality, Integrity, Availability) Model for information security is addressed in several ways by the use of a secure communications protocol. Confidentiality of the information being passed is the main purpose of the SSL and TLS protocols. Integrity is addressed through the use of message authentication in each message from the first handshake. Additionally, non-repudiation is accounted for through certificate passing in addition to the integrity check from the message authentication. Though more responsibility for the Availability portion of the model (in this example) is placed on the server, Availability is slightly addressed since secure communications prevent malicious users from having direct access to the system. 

Difference between SSL and TLS

---

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are both cryptographic protocols designed to provide communications security over a computer network. The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1.  In this document, the US Government describes TLS Guidelines for Implementation and indicates that SSL v3 not be used for sensitive government communications or for HIPAA-compliant communications.  This chart does a good job with SSL/TLS support in browsers and the affected vulnerabilities (BEAST, POODLE, CRIME, RC4). 

No SSL

---

Of course with no SSL data across the network is not encrypted.   Using no SSL is usually done in a development or test environment.   

2-way SSL (Mutual or Client Authentication)

---

In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.

Two-way SSL authentication is also referred to as client or mutual authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.

Establishing the encrypted channel using certificate-based 2-Way SSL involves:

1. A client requests access to a protected resource.
2. The server presents its certificate to the client.
3. The client verifies the server’s certificate.
4. If successful, the client sends its certificate to the server.
5. The server verifies the client’s credentials.
6. If successful, the server grants access to the protected resource requested by the client.

1-Way SSL

---

In such mode, the SSL-client application is not verified by the SSL-server application. Only the server is verified.

References:

---

http://www.sans.org/reading-room/whitepapers/protocols/ssl-tls-beginners-guide-1029

http://blog.vanillaforums.com/help/using-ssl-https-vanilla-forum/

http://en.wikipedia.org/wiki/Public_key_certificate
https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html
http://en.wikipedia.org/wiki/Transport_Layer_Security
https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html
http://mihalos.gr/2013/04/03/ssltls-protocol-overview-part1/
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

Web Application Security Top 10

OWASP (Open Web Application Security Project) is an organization focused on improving security of software.  Their mission is to make software security visible so that individuals and organizations can make informed decisions about software security risks.  They published a Top Ten document to promote awareness for Web Application Security.   The top ten represents the most critical web application security flaws.  A couple of points on the top 10:

• They have many international versions of the Top 10 list.  
• The Top 10 continues to change and evolve.  
• There are hundreds of issues that can possibly affect Web Application Security so don't stop with mitigating the top 10.  OWASP has several resources that can assist such as the OWASP Developer's Guide, OWASP Cheat Sheet Series, OWASP Testing Guide and the OWASP Code Review Guide.

The OWASP Top 10 is a list of the 10 Most Critical Web Application Security Risks and for each Risk it provides:

• A description
• Example vulnerabilities
• Example attacks
• Guidance on how to avoid
• References to OWASP and other related resources

You can see these details of each risk at the OWASP Project site here.  I included the overview list below which is also here..

Authentication Factors and Identity

Sometimes there is a confusion between Identification and Authentication.  So in this article I want to touch on Identification and Authentication then discuss the factors of authentication.

What is the difference between Identification and Authentication?

• Identification is normally the way to describe a user, or principal, such as a username, email, etc.  "I am Bob"
• Authentication is a way of proving and confirming the user, or principal is who they say they are.  "I am Bob because my password is ****"
• An additional term that may come up when looking at Identification and Authentication is Non-Repudiation which is to ensure that a transferred message has been sent and received by the parties claiming to have sent and received the message.  This guarantees that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message.

What are the Authentication Factors

Type 1

Type 1 is normally the Knowledge Factor that describes things only the user knows.  Examples are:

• Passwords
• PINs
• Passphrases

Because of weak passwords, brute force password hacking and password recovery techniques, Multifactor authentication is being offered more frequently to counteract hacking threats.  We will touch on that in a moment.

Type 2

Type 2 is normally the Ownership Factor that describes something you have.  Examples are:

• Token Devices
• Cryptographic Keys
• Smart Cards

Type 3

Type 3 is normally the Inherence Factor that describes something you are.  Examples are usually around biometrics such as:

• Fingerprints
• Retinal Scans
• Iris Scans
• Hand Geometry
• Voice

Type 4

Type 4 is a new Factor that has been introduced that describes where you are or my location.  Examples are usually  Real Time Locating Systems (RTLS):

• Personal Tag Beacons
• GPS Devices

Multi-factor

Multi-factor authentication (MFA) enforces at least 2 of the authentication factors such as a password and fingerprint. So MFA combines 2 or more independent credentials. Requiring more than 1 factor usually decreases the ease of hacking or providing false credentials which in turn improves security and reduces data theft.  Examples include:

• Swiping a card and entering a PIN.
• Logging into a website and being requested to enter an additional one-time password (OTP) that the website's authentication server sends to the requester's phone or email address.
• Swiping a card, scanning a fingerprint and answering a security question.

The CIA Triad and JBoss

What is the CIA Triad?

The CIA Triad is related to three primary issues for Information Security - Confidentiality, Integrity and Availability.  We will briefly discuss those and how they apply to JBoss Middleware.  The CIA Triad is part of Domain 1, Information Security Governance and Risk Management, of the Certified Information Systems Security Professional (CISSP) Common Body of Knowledge (CBK).   There are some supplements to this model which are Authenticity, Accountability and Non-repudiation that we will discuss in later postings.

Confidentiality

Confidentiality provides the ability to keep information private and secure.  This ensures the required level of secrecy is enforced at each point and that unauthorized disclosure is prevented.  Confidentiality can be considered as secrecy, privacy and sensitivity.  Confidentiality is the opposite of disclosure.  Confidentiality can be provided by:

• Data encryption services during transmission and storage
• Authentication and Authorization Services
• Network Security Protocols

Examples to ensure Confidentiality is used within our JBoss environment:

• 2-way SSL with Application Servers and Containers
• FIPS 140-2 Compliant Passwords
• Java Authentication and Authorization Service (JAAS)
• Single Sign On with SAML
• Authorization with XACML

Additional Information for the JBoss Enterprise Application Platform and JBoss Fuse can be found in these references:

• https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/pdf/Security_Guide/JBoss_Enterprise_Application_Platform-6.3-Security_Guide-en-US.pdf
• https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Security_Guide/files/front.html

Integrity

Integrity ensures that data that is sent is the data received and the data has not been altered, intentionally or unintentionally.  So the reliability of information and systems is safeguarded while unauthorized modification of data is prevented.   An additional way to look at Integrity is that a message or data is complete and authentic.   The opposite of Integrity is alteration.  Integrity can be provided by:

• Firewall Services
• Intrusion Detection Services
• Cryptographic Services

Examples to ensure Integrity is used within our JBoss environment:

• Message Encryption and signing provide integrity as well as confidentiality

Additional Information for the JBoss Enterprise Application Platform and JBoss Fuse can be found in these references:

• https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/front.html

Availability

Availability refers to the reliability and stability of the network and systems.  The environment should provide the sufficient capacity in order to perform in a predictable way with a tolerable level of performance.   The opposite of Availability is destruction.  Availability ensures:

• Connectivity is accessible when needed which allows authorized uses access
• Guarantee of service
• Performance
• Up time

Although some of these are not thought of as pure security, they are affected by attacks.  So Availability ensures the reliability and timely access to data and resources by authorized actors.    Examples to ensure Availability is used within our JBoss environment:

• Fabric to enable high availability
• Replicated services
• Load Balancing and High Availability Clusters
• Fault Tolerant Messaging

Additional Information for the JBoss Enterprise Application Platform and JBoss Fuse can be found in these references:

• https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Configuring_Web_Service_Endpoints/files/FabricHA.html
• https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/pdf/Administration_and_Configuration_Guide/JBoss_Enterprise_Application_Platform-6.3-Administration_and_Configuration_Guide-en-US.pdf

Government Certification and Accreditation Made Easy

I wanted to highlight this week the resources that will help you with Government certifications and Accreditations. There is a great resource page that highlights everything but I wanted to list the middleware specific ones below. These will help you comply with a variety of the government Requirements. You can find the government standards page here.

Common Criteria Certification (CCC):
JBoss EAP 5 is EAL4+ Certified. You can find the configuration guide here.

JBoss EAP 6.2 is being evaluated for EAL4+ Certification. You can find more about the certification process here.

There are some tools that help with compliance:
OpenSCAP is a tool for running Security Content Automation Protocol (SCAP) content. The project is the upstream for the openscap tool that ships in Red Hat Enterprise Linux.

The SCAP Workbench provides a simpler interface for creating and editing SCAP content.

The Baseline compliance content in SCAP formats is located on github  - https://github.com/OpenSCAP/scap-security-guide

Communities that help:

The Red Hat-sponsored gov-sec community is a moderated mailing list for US government security professionals.

Military Open Source Working Group (Mil-OSS) is a community of open source enthusiasts in the DOD. It is not affiliated with Red Hat in any way, but many Red Hat folks are active members. If you are interested in any of the information on this page, there's a good chance you'll enjoy this group. You can find more information on the Mil-OSS website.

SCAP Security Guide Source Migration

The SCAP Security Guide (SSG) Project has been hosted on FedoraHosted (https://fedorahosted.org/scap-security-guide/).  The scap-security-guide project (SSG) delivers security guidance, baselines, and associated validation mechanisms utilizing the ​Security Content Automation Protocol (SCAP). 

The project provides practical security hardening advice for Red Hat products, and also links it to compliance requirements in order to ease deployment activities, such as certification and accreditation. These include requirements in the U.S. government (Federal, Defense, and Intelligence Community) as well as of the financial services and health care industries. For example, high-level and widely-accepted policies such as ​NIST 800-53 provides prose stating that System Administrators must audit "privileged user actions," but do not define what "privileged actions" are. The SSG bridges the gap between generalized policy requirements and specific implementation guidance, in SCAP formats to support automation whenever possible.

The source tree is now hosted on Github (https://github.com/OpenSCAP/scap-security-guide).  You will find JBoss EAP 5 and Fuse 6 SCAP Content in the repository.

As part of this process we'll be starting up Pull Requests, which means we volunteers who are willing to review patch submissions and approve their merge in the GitHub repo. 

Here's how to help:
---The GitHub page is https://github.com/OpenSCAP/scap-security-guide. On that page you'll be able to set your 'Watch' preferences:
* EMailed when ANYTHING happens on the site - tickets, patches, etc
* EMailed when someone asks or mentions the project (e.g., submit a pull request and says @OpenSCAP/scap-security-guide can I get a review plz?"
* EMailed never, ever
If you set your watch permissions to "Watching" you'll receive notes when people issue pull requests. This would be the notification to login and review the patch.
---Join the SSG Content Authors team: https://github.com/orgs/OpenSCAP/teams/ssg-content-authors  This gives you commit rights on the new repo.