Friday, November 20, 2015

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.

Friday, October 30, 2015

Webinar: How to become a data-driven organization to achieve more and gain a competitive edge







Data-driven companies share characteristics that help them achieve more and gain a competitive advantage within their industry. The importance of data-driven thinking is not new, but what does it mean in practice?

Red Hat and Mammoth Data deliver a modern, cloud-ready architecture using Hadoop and Spark to transform your organization into a data-driven one.

Join this webinar to learn about:
  • What a data driven company is and what the challenges are to becoming one
  • Moving to real time—the stages of data-driven transformation
  • Data consolidation and analytics
  • Computer-aided decision making
  • Real-time decision making:
    • The semantic web, natural language, and “everything-as-a-service”
    • Modern data architecture and solutions
A case study, using a real-world situation, will also be a part of this webinar.
    Speakers: 

    Syed Rasheed, sr. product marketing manager, Red Hat
    Andrew C. Oliver, president and founder, Mammoth Data

    Join the live event:
    Time zone converter
    • Tuesday, November 17, 2015 | 11 a.m. EDT | 8 a.m. PDT

    Wednesday, October 21, 2015

    Using the Unified Push Server with BPMS

    During this past Red Hat Summit I worked on a session with Mobile, Fuse and BPMS.  It was a great pleasure working with Phil SimpsonJavier Perez and  Maggie Hu to build and present the demo.  Below I walk through setting up and using the Push Notification Server.  For information on submitting claims through the mobile application and the adjudicator review you can review Maggie's Blog on Red Hat Mobile Application Platform - Connecting to JBoss BPMSuite REST.

    Red Hat Summit 2015 - 
    Photo Taken by Wanja Pernath

    This article is part of a series we're putting together for the Build an Enterprise Application in 60 Minutes with JBoss Middleware session at the Summit. The original slide decks can be found below from Maggie on Slideshare. Please take a look at the slide decks to get a better idea on the use case we're working with.

    Basically, we're allowing people to submit claims quickly from their mobile devices with some basic information when an auto accident happens. The claim will get submitted to the insurance company, an adjudicator will review the claim, set the settlement amount, and complete the claim. Then the policy holder will receive a push notification on their mobile device on the settlement amount.




    What is Push Notification and its benefits?

    A push notification is a message or alert delivered by a centralized server (on premise or cloud) to a device.   Unlike pull notifications, in which the client must request information from a server, push notifications originate from a server. Typically, the end user must opt-in to receive alerts; opt-in usually takes place during the install process and end users are provided with a way to manage alerts if they change their minds later on.

    An important advantage of push notifications in mobile computing is that the technology doesn't require specific applications on a mobile device to be open in order for a message to be received. This allows a smartphone to receive and display social media or text message alerts even when the device's screen is locked and the social media application that is pushing the notification is closed.

    The Red Hat Mobile Unified Push Server (Aerogear) can be seen as a broker that distributes push messages to different 3rd party Push Networks. The graphic below gives a little overview:


    1. One PushApplication and at least one mobile platform variant must be created.
    2. The variant credentials that are generated and stored by the UnifiedPush Server must be added to the mobile application source, enabling the application to register with the UnifiedPush Server once it is installed on mobile devices.
    3. Sending a push message can happen in different ways: The AdminUI can be used to send a (test) message to registered devices. However, in a real-world scenario the Push Notification Message request is triggered from a backend application, which sends its requests using the Sender API. Different SDKs for different languages are supported.
    4. The push request is then translated into platform specific details for the required variant Push Network. The Dashboard of the AdminUI gives a status report if a message is sent to the Push Network.
    5. The UnifiedPush Server does not directly deliver the message to the mobile device. This is done by the appropriate variant Push Network. Note: There can be latency in the actual delivery. Most Push Networks, such as APNs or GCM, do not guarantee to deliver messages to mobile devices.
    Setting Up the Unified Push Server on Openshift

    The Unified Push Server allows developers to send native push messages to Apple’s Push Notification Service (APNS) and Google’s Cloud Messaging (GCM). It features a built-in administration console that makes it easy for developers to create and manage the push related aspects of their applications for any mobile development environment. Includes client SDKs (iOS, Android, & Cordova), and a REST based sender service with an available Java sender library.

    In our example we setup the UPS on Openshift instead of on premise and we do this through the Openshift Application Manager.  First we need a Openshift account.  You can sign up for a free account for 3 small gears.


    Next we will create an openshift application.


    We will use the Unified Push Server 1.0 Cartridge which will also add MySQL to the Application.  We can take the defaults and click Create Application Button.  After creating the application a credentials screen is displayed with URLs and credentials.


    Now we can sign onto the console to create applications, variants, etc and monitor messages.  Let's open the dashboard for the Push Server, ie https://jbossunifiedpushtest2-ossmentor.rhcloud.com/ag-push, and login with admin/admin which will bring up the dasboard main screen.


    Now we want to add an application to receive the push notifications.  We click on applications and the create application button.  Once created we can look at the variants.  This shows the application ID and Master Secret for the application which we will use in our example.



    At this point we can create variants for Android and iOS.   For this first example we will create an application but won't use variants and register devices.  We will just show the notification getting to the push notification server.  Now that the application is created let's do a quick test.

    Test sending a message to the UPS

    I used the Advanced REST Client in Chrome to test the message.  I setup the project with the URL, the Authorization and Content Type as shown below.  I put in some sample data for the notification.


    After clicking on send I get a Job submitted response and can lookup the message in the dashboard.



    Now let's move onto how we can make the call from BPMS.

    Sending a notification message from BPMS to the UPS



    First in our Business Process we add the message in a script task to the Response Body for the REST call.

    kcontext.setVariable("requestBody","{\"ttl\":3600,\"message\":{\"alert\":\"Your Payment Amount is:"+kcontext.getVariable("paymentAmount")+"\",\"action-category\":\"some value\",    \"sound\":\"default\",\"badge\":2,\"content-available\":true},\"simple-push\":\"version=123\"}");

    Next in our Business Process we added a REST Task to make the call to the UPS to send the claim award message.  A couple of items to note on the Task.  The first is the data assignments.  The username is the Application ID and the password is the Master Secret as seen in the screen shots below.  Also note the URL for the domain REST API for UPS in addition to the Basic Authorization.




    Note the App settings in addition to the Android Variant settings for Google Cloud messaging.
    Also in the REST Task we setup the Data Input and Output as indicated below.

    One additional item that was required is the work definition as displayed below.

    import org.drools.core.process.core.datatype.impl.type.StringDataType;
    import org.drools.core.process.core.datatype.impl.type.ObjectDataType;
    [
      [
        "name" : "Email",
        "parameters" : [
          "From" : new StringDataType(),
          "To" : new StringDataType(),
          "Subject" : new StringDataType(),
          "Body" : new StringDataType()
        ],
        "displayName" : "Email",
        "icon" : "defaultemailicon.gif"
      ],
      [
        "name" : "Log",
        "parameters" : [
          "Message" : new StringDataType()
        ],
        "displayName" : "Log",
        "icon" : "defaultlogicon.gif"
      ],
      [
        "name" : "WebService",
        "parameters" : [
            "Url" : new StringDataType(),
             "Namespace" : new StringDataType(),
             "Interface" : new StringDataType(),
             "Operation" : new StringDataType(),
             "Parameter" : new StringDataType(),
             "Endpoint" : new StringDataType(),
             "Mode" : new StringDataType()
        ],
        "results" : [
            "Result" : new ObjectDataType(),
        ],
        "displayName" : "WS",
        "icon" : "defaultservicenodeicon.png"
      ],
      [
        "name" : "Rest",
        "parameters" : [
            "Url" : new StringDataType(),
            "Method" : new StringDataType(),
            "ConnectTimeout" : new StringDataType(),
            "ReadTimeout" : new StringDataType(),
            "Username" : new StringDataType(),
            "Password" : new StringDataType()
        ],
        "results" : [
            "Result" : new ObjectDataType(),
        ],
        "displayName" : "REST",
        "icon" : "defaultservicenodeicon.png"
      ]
    ]
    That was all that is required to send a push notification from BPMS to the Unified Push server.  You can see the messages in the UPS console.
    All variants associated with the Application in UPS will receive the notification.  We will cover the Android application in a follow up article to register the device with Google Cloud Messaging (GCM) and receive the notification. 

    References:
    http://searchconsumerization.techtarget.com/definition/push-notification
    https://aerogear.org/docs/unifiedpush/ups_userguide/index/
    https://developers.openshift.com/en/xpaas-unified-push.html

    Monday, October 19, 2015

    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 (alwong@redhat.com)


    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.

    Thursday, October 15, 2015

    Webinar: Build your next business application in 60 minutes

    IT is at the center of change in application development as new approaches like DevOps emphasize rapid delivery of features and greater participation by end users and “citizen developers.” Middleware technologies such as integration, business rules, business process management (BPM), mobile application platforms, and Platform-as-a-Service (PaaS) are emerging as important tools for DevOps teams, greatly reducing the traditional coding requirements for new business applications.

    Join us for this webinar to learn how two middleware technologies—business process management and mobile app development platforms—can work together in the cloud to support development of process-enabled mobile business apps. Through a real-word use case, we will demonstrate:
    • Development and deployment of a mobile business app using Red Hat® Mobile Application Platform.
    • Platform inclusion of captured mobile information into business processes with Red Hat JBoss® BPM Suite.
    • Integration of automated processes with systems of record with Red Hat JBoss Fuse.
      Speakers:
      Phil Simpson, senior principal product marketing manager, Red Hat
      Maggie Hu, middleware specialist solution architect, Red Hat
      Kenny Peeples, JBoss technology evangelist, Red Hat

      Join the live event:
      Time zone converter
      • Thursday, October 22, 2015 | 11 a.m. EDT | 8 a.m. PDT
      Register Now

      Wednesday, October 14, 2015

      Data as a Service: JBoss Data Virtualization and Hadoop powering your Big Data solutions

      Guest blog by Syed Rasheed, Senior Product Marketing Manager
      Twitter @Junooni, eMail srasheed@redhat.com


      Red Hat and Cloudera, announce the formation of a strategic alliance. From JBoss perspective, the key objective of the alliance is to leverage big data enterprise-wide and not let Hadoop become another data silo. Cloudera combined with Red Hat JBoss Data Virtualization integrates Hadoop with existing information sources including data warehouses, SQL and NoSQL databases, enterprise and cloud applications, and flat and XML files. The solution creates business-friendly, reusable and virtual data models with unified views by combining and transforming data from multiple sources including Hadoop. This creates integrated data available on-demand for external applications through standard SQL and web services interfaces.
      The reality at vast majority of organization is that data is spread across too many applications and systems. Most organizations don’t know what they’ve lost because their data is fragmented across the organization. This problem does not go away just because an organization is using big data technology like Hadoop; in fact, they get more complicated. Some organizations try to solve this problem by hard coding the access to data stores. This simple approach inefficiently breaks down silos and brings lock-in with it. Lock-in makes applications less portable, a key metric for future proofing IT. This approach also impedes organizational agility because hard coding data store access is time consuming and makes IT more complex, incurring technical debt. Successful business need to break down the data silos and make data accessible to all the applications and stakeholders (often a requirement for real time contextual services).
      redhat-jboss-datavirt
      A much better approach to solving this problem is abstraction through data virtualization. It is a powerful tool, well suited for the loose coupling approach prescribed by the Modern Enterprise Model. Data virtualization helps applications retrieve and manipulate data without needing to know technical details about each data store. When implemented, organizational data can be easily accessed using a simple REST API or via familiar SQL interface.
      Data Virtualization (or an abstracted Data as a Service) plugs into the Modern Enterprise Platform as a higher-order layer, offering the following advantages:
      • Better business decisions due to organization wide accessibility of all data
      • Higher organizational agility
      • Loosely coupled services making future proofing easier
      • Lower cost
      Data virtualization is therefore a critical part of the big data solution. It facilitates and improves the use of big data in the enterprise by:
      • Abstracting big data into relational-like views
      • Integration with existing enterprise sources
      • Adding real time query capabilities to big data
      • Providing full support for standard based interfaces like REST and OData in addition JDBC and ODBC.
      • Adding security and governance to the big data infrastructure
      • Flattening data siloes through a unified data layer.
      Want to learn more, download, and get started with JBoss Data Virtualization visit http://www.jboss.org/products/datavirt
      Data Virtualization by Example https://github.com/datavirtualizationbyexample
      Interested in community version then visit http://teiid.jboss.org/

      Be Sociable, Share!