REVIEW: “Security for Service Oriented Architectures”, Walter Williams


“Security for Service Oriented Architectures”, Walter Williams, 2014,
978-1466584020, U$61.97
%A Walter Williams
%C #300 – 6000 Broken Sound Parkway NW, Boca Raton, FL 33487-2742
%D 2014
%G 978-1466584020 1466584025
%I CRC Press
%O U$61.97 800-272-7737
%O Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P 329 p.
%T “Security for Service Oriented Architectures”

Walt Williams is one of the sporadic, but thoughtful, posting members of the international CISSP Forum. He has come up with a significant text on an important topic.

After some preface and introduction, the book starts in chapter two, defining the four kinds of architecture in computer systems: infrastructure, software, data, and security. This chapter covers foundational concepts, as well as service oriented architecture SOA), and is, alone, worth the price of the book.

Chapter three, on implementation, comprises the bulk of the space in the work, and is primarily of interest to those dealing with development, although it does have a number of points and observations of use to the manager or security practitioner. “Web 2.0” (chapter four) has some brief points on those advanced usages. A variety of additional SOA platforms are examined in chapter five. Chapter six, on the auditing of SOA applications, covers not only the how, but also notes specific types of attacks, and the most appropriate auditing tools for each case. Much the same is done, in terms of more general protection, in chapter seven. Chapter eight, simply entitled “Architecture,” finishes off with sample cases.

It is an unfortunate truism that most security professionals do not know enough about programming, and most programmers don’t care anything about security. This is nowhere truer than in service oriented architecture and “the cloud,” where speed of release and bolt-on functionality trumps every other consideration. Williams’ work is almost alone in a badly under-served field. Despite a lack of competition, it is a worthy introduction. I can recommend this book to anyone involved in either security or development, particularly those working in that nebulous concept known as “the cloud.”

copyright, Robert M. Slade 2015 BKSECSOA.RVW 20150130

Hardening guide for Tomcat 8 on RedHat 6.5 (64bit edition)

This document explains the process of installation, configuration and hardening of Tomcat 8.x server, based on RedHat 6.5 default installation (IPTables and SELinux enabled by default), including support for TLS v1.2 and protection from
BEAST attack and CRIME attack.
Some of the features explained in this document are supported by only some of the Internet browsers:

  • TLS 1.2 – Minimum browser support: IE 8.0 on Windows 7/8 (Need to be enabled by default), Firefox 24.0 (Need to be enabled by default), Chrome 30, Opera 17, Safari 5.0
    Installation phase

  1. Login to the server using Root account.
  2. Create a new account:
    groupadd tomcat
    useradd -g tomcat -d /home/tomcat -s /bin/sh tomcat
  3. Download the lastest JDK8 for Linux from:
  4. Upgrade to the latest build of Oracle JDK:
    rpm -Uvh /tmp/jdk-8u45-linux-x64.rpm
  5. Delete the JDK8 source files:
    rm -rf /tmp/jdk-8u45-linux-x64.rpm
    rm -rf /usr/java/jdk1.8.0_45/
  6. Download the latest Tomcat 8 source files:
    cd /opt
  7. Extract Tomcat source files:
    tar zxf /opt/apache-tomcat-8.0.21.tar.gz -C /opt
  8. Rename the Tomcat folder:
    mv /opt/apache-tomcat-8.0.21 /opt/tomcat
  9. Remove default content:
    rm -rf /opt/apache-tomcat-8.0.21.tar.gz
    rm -rf /opt/tomcat/webapps/docs
    rm -rf /opt/tomcat/webapps/examples
    rm -rf /opt/tomcat/webapps/ROOT/RELEASE-NOTES.txt
    rm -rf /opt/tomcat/webapps/host-manager
    rm -rf /opt/tomcat/webapps/manager
    rm -rf /opt/tomcat/work/Catalina/localhost/docs
    rm -rf /opt/tomcat/work/Catalina/localhost/examples
    rm -rf /opt/tomcat/work/Catalina/localhost/host-manager
    rm -rf /opt/tomcat/work/Catalina/localhost/manager
  10. Change folder ownership and permissions:
    chown -R tomcat.tomcat /opt/tomcat
    chmod g-w,o-rwx /opt/tomcat
    chmod g-w,o-rwx /opt/tomcat/conf
    chmod o-rwx /opt/tomcat/logs
    chmod o-rwx /opt/tomcat/temp
    chmod g-w,o-rwx /opt/tomcat/bin
    chmod g-w,o-rwx /opt/tomcat/webapps
    chmod 770 /opt/tomcat/conf/catalina.policy
    chmod g-w,o-rwx /opt/tomcat/conf/
    chmod g-w,o-rwx /opt/tomcat/conf/context.xml
    chmod g-w,o-rwx /opt/tomcat/conf/
    chmod g-w,o-rwx /opt/tomcat/conf/server.xml
    chmod g-w,o-rwx /opt/tomcat/conf/tomcat-users.xml
    chmod g-w,o-rwx /opt/tomcat/conf/web.xml
  11. Move to the folder /opt/tomcat/lib
    cd /opt/tomcat/lib
  12. Extract the file catalina.jar
    jar xf catalina.jar org/apache/catalina/util/
  13. Edit using VI, the file /opt/tomcat/lib/org/apache/catalina/util/
    Replace the string below from: Tomcat/8.0.21
    To: Web serverReplace the string below from:

    Replace the string below from:
    server.built=Mar 23 2015 14:11:21 UTC
    server.built=Jan 01 2000 00:00:00 UTC

  14. Move to the folder /opt/tomcat/lib
    cd /opt/tomcat/lib
  15. Repackage the file catalina.jar
    jar uf catalina.jar org/apache/catalina/util/
  16. Remove the folder below:
    rm -rf /opt/tomcat/lib/org
  17. Edit using VI, the file /opt/tomcat/conf/server.xml and make the following changes:
    Replace the:
    <Connector port="8080" protocol="HTTP/1.1"
    redirectPort="8443" />

    <Connector port="8080" protocol="HTTP/1.1"
    redirectPort="8443" />
    Replace the:
    <Server port="8005" shutdown="SHUTDOWN">
    <Server port="-1" shutdown="SHUTDOWN">

    Replace the:

  18. Create using VI, the file error.jsp inside the application directory (example: /opt/tomcat/webapps/ROOT/error.jsp) with the following content:
    <title>404-Page Not Found</title>
    <body> The requested URL was not found on this server. </body>
  19. Edit using VI, the file /opt/tomcat/conf/web.xml and add the following sections, before the end of the “web-app” tag:
    <location>/error.jsp </error-page><!-- Define a Security Constraint on this Application -->
    <web-resource-name>HTMLManger and Manager command</web-resource-name>
  20. Create using VI, the file /etc/init.d/tomcat, with the following content:
    # description: Tomcat Start Stop Restart
    # processname: tomcat
    # chkconfig: 234 20 80
    export JAVA_HOME
    export PATH
    case $1 in
    /bin/su tomcat $CATALINA_HOME/
    /bin/su tomcat $CATALINA_HOME/
    /bin/su tomcat $CATALINA_HOME/
    /bin/su tomcat $CATALINA_HOME/
    exit 0

    Note: Update the “JAVA_HOME” path according to the install JDK build.
  21. Change the permission on the tomcat script:
    chmod 755 /etc/init.d/tomcat
  22. To start Tomcat service at server start-up, run the command:
    chkconfig tomcat on
  23. To manually start the Tomcat service, use the command:
    service tomcat start
  24. Configure IPTables:
    service iptables stop
    iptables -P INPUT DROP
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  25. Allow SSH access from Internal segment (i.e.
    iptables -A INPUT -m state --state NEW -p tcp --dport 22 -s -j ACCEPT
    Note: Replace with the internal segment and subnet mask.
  26. Allow HTTP (Port 8080TCP) access from the Internet on the public interface (i.e. eth0)
    iptables -A INPUT -m state --state NEW -p tcp --dport 8080 -i eth0 -j ACCEPT
    Note: Replace eth0 with the public interface name.
  27. Save the IPTables settings:
    service iptables save
    SSL Configuration Phase

  1. Login to the server using Root account.
  2. Create folder for the SSL certificate files:
    mkdir -p /opt/tomcat/ssl
    chown -R tomcat:tomcat /opt/tomcat/ssl
    chmod -R 755 /opt/tomcat/ssl
  3. Run the command below to generate a key store:
    /usr/java/jdk1.8.0_45/bin/keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 2048 -keystore /opt/tomcat/ssl/server.key -storepass ComplexPassword -validity 1095 -alias "FQDN_Name"
    Note 1: The command above should be written as one line.
    Note 2: Replace ComplexPassword with your own complex password.
    Note 3: Replace “FQDN_Name” with the server DNS name.
  4. Run the command below to generate a CSR (certificate request):
    /usr/java/jdk1.8.0_45/bin/keytool -certreq -keyalg "RSA" -file /tmp/tomcat.csr -keystore /opt/tomcat/ssl/server.key -storepass ComplexPassword -alias "FQDN_Name"
    Note 1: The command above should be written as one line.
    Note 2: Replace ComplexPassword with your own complex password.
    Note 3: Replace “FQDN_Name” with the server DNS name.
  5. Send the file /tmp/tomcat.csr to a Certificate Authority server.
  6. As soon as you receive the signed public key from the Certificate Authority server (usually via email), copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as “server.crt
  7. Copy the file “server.crt” using SCP into /opt/tomcat/ssl
  8. Follow the link on the email from the CA server, to create the Root CA chain, and save it as “ca-bundle.crt” (Note: The file must be PEM (base64) encoded).
  9. Copy the file “ca-bundle.crt” using SCP into /opt/tomcat/ssl
  10. Run the command below to import the trusted root CA public certificate:
    /usr/java/jdk1.8.0_45/bin/keytool -import -alias "FQDN_Name" -keystore /opt/tomcat/ssl/server.key -storepass ComplexPassword -trustcacerts -file /opt/tomcat/ssl/ca-bundle.crt
    Note 1: The command above should be written as one line.
    Note 2: Replace ComplexPassword with your own complex password.
    Note 3: Replace “FQDN_Name” with the server DNS name.
  11. Run the command below to import the signed public key into the key store:
    /usr/java/jdk1.8.0_45/bin/keytool -import -keystore /opt/tomcat/ssl/server.key -storepass ComplexPassword -trustcacerts -file /opt/tomcat/ssl/server.crt
    Note 1: The command above should be written as one line.
    Note 2: Replace ComplexPassword with your own complex password.
  12. Stop the Tomcat service:
    service tomcat stop
  13. Edit using VI, the file /opt/tomcat/conf/server.xml and add the section below:
    <Connector port="8443"
    sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" />

    Note 1: Replace ComplexPassword with your own complex password.
    Note 2: Replace “FQDN_Name” with the server DNS name.
  14. Edit using VI, the file /opt/tomcat/conf/web.xml and add the following sections, before the end of the “web-app” tag:
    Constrain the user data transport for the whole application
  15. Edit using VI, the file /opt/tomcat/conf/context.xml and add the following parameter inside the context tag:
  16. Allow HTTP (Port 8080TCP) access from the Internet on the public interface (i.e. eth0)
    iptables -A INPUT -m state --state NEW -p tcp --dport 8443 -i eth0 -j ACCEPT
    Note: Replace eth0 with the public interface name.
  17. Save the IPTables settings:
    service iptables save
  18. To manually start the Tomcat service, use the command:
    service tomcat start
    The original post can be found at

REVIEW: “The Social Life of Information”, John Seely Brown/Paul Duguid

BKSCLFIN.RVW   20130124

“The Social Life of Information”, John Seely Brown/Paul Duguid, 2000,
0-87584-762-5, U$24.95
%A   John Seely Brown
%A   Paul Duguid
%C   60 Harvard Way, Boston MA   02163
%D   2000
%G   0-87584-762-5
%I   Harvard Business School Press
%O   U$25.95 617-495-6947 617-495-6700 617-495-6117 800-545-7685
%O   Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P   320 p.
%T   “The Social Life of Information”

The introduction is vague, but basically notes that those who approach information in a strictly technical or business sense risk failure by ignoring the social context in which information resides.  Information does not exist of itself, but is produced and consumed by people, and thus is a construct and artifact of our social environment.

Chapter one talks about information overload.  Bots are discussed in chapter two: not the botnets (simple programs distributed over multiple computers) that everyone agrees should be eliminated, but the range of software agents that we use without thinking.  The authors note that the interactions between these bots are inherently impossible to control, and the material prophecies the recent problems in content blocking such as affected the Hugo awards and Michelle Obama.  Chapter three examines various social issues of home (or non-office) -based work.  The difference between our processes, and the way people actually work, are addressed in chapter four.  A number of interesting ideas are raised, but it is (ironically) difficult to see how to put these into practice (rather than discussion of what we should do).  Chapter five turns to learning and knowledge management.  The authors assert that learning is primarily social, and note negative effects on business if this aspect is ignored, but actually say very little about learning or information.  Chapter six explores innovation in respect to the Internet and a global economy, noting that information is difficult to control in that it is both “sticky” (resistant to change) and “leaky” (incidental disclosures of “confidential” information abound).  The “background” of information is noted in chapter seven, with the authors examining the resilience of paper in the face of a determined effort to create the “paperless” office.  They note studies showing that “printing” out email seemed to automatically give the data greater weight.  (I wonder if this might have changed in today’s marketplace: sadly, a rather large proportion of people now seem to hold that *anything* found on the Internet, regardless of how silly, must be true.)  Chapter eight, entitled “Re-education,” discusses the changing nature of universities.

There is an afterword, “Beyond Information,” touching on miscellaneous points, particularly to do with copyright.

Despite a certain lack of structure or purpose to some of the sections, the writing is both clear and entertaining.  It also has that ineffable quality of readability, meaning that the reading is enjoyable even when the authors are not delivering specifically interesting information, or making a vital point in an argument.  It’s a joy simply to consume the text.

copyright, Robert M. Slade   2013   BKSCLFIN.RVW   20130124

Developing an IR Process and Team

In our world today, we have an abundance of many things, among which are –unexpected events. Falling meteorites, terrorist attacks, hacktivist demonstrations, blackouts, tsunamis…. well, you get the point.Now, although the majority of events I just mentioned probably fall into a Disaster Recovery category, they are nonetheless events that greatly impact our personal lives and disrupt the normal ebb and flow of the daily routine.On the professional side of life, there are also incidents that,although classified on a lower scale than a disaster, still create much disruption and depending on how they are handled, can have a long-lasting impact to the flow of business. The purpose of this article is to discuss some suggested methods of how to go about building an incident response team and related procedures that will enable this group to respond to these events expeditiously.


Before we start to discuss the mechanics behind building this elite group of technical emergency responders, let’s understand what we’re up against. First of all, let’s get our terminology straight. What exactly am I referring to when I use the term – “event” and “incident“? To give this article some context, consider the following definitions courtesy of Merriam Webster…

  • An incident is defined as “an occurrence […] that is a separate unit of experience”.
  • An event can be defined as “something that happens: an occurrence” or “a noteworthy happening”.

Let’s break this down;if we use the example of a small electrical fire in the basement of a building, this can be categorized as an individual “incident” or as a “separate unit of experience”. Now, if this incident is not handled properly, it can escalate and possibly grow to become a fire so large that it consumes the entire building. The incineration of the building can be categorized as an “event“, which is sort of an umbrella term that groups causes and effects for the entire disaster or “noteworthy happening” into one category.

Applying this understanding to the enterprise, items such as a data breaches, hacking attempts, critical server crashes, website defacement or social engineering attempts can be classified as individual “incidents”. This is because they may affect business or the corporate reputation but may not completely halt the business flow of the company. If not addressed properly, these incidents,although small,could escalate and succeed in completely halting the business,resulting in a disaster or large scale “event“. Hopefully, this explanation clarifies the difference between events and incidents as this understanding will determine how each occurrence is handled. This now brings us to our next section…


This step can seem daunting if you’ve never been involved with Incident Response or you’re trying to decide where a process like this might fit in to your particular environment. How can we go about organizing all the related business groups, technical areas and how can we find out if we’re missing anything?The good news is that in the majority of cases, there is already some type of set process that is followed whenever incidents occur. Some problems that come up, however, could be that the process may not be documented and since it’s an informal process, there is a great chance that core response components are missing or have been overlooked. The benefit to identifying any existing process that your organization may have is that it is much easier to train employees using a foundation with which they are already accustomed to. It may also be much easier to gain upper management’s support and buy-in for a process that is actively being followed albeit – informally.This support is necessary because management’s support will be needed for any funding that is required and for the allocation of time for the individuals that will be forming part of the official team. Without this support, it’s possible that your project will never get off its feet or after all the hard work,the process could be scrapped or drastically changed and then it’s back to the proverbial drawing board. This can beextremely frustrating so be sure to do your homework, identify any area that may already be built and if appropriate, incorporate this into your draft IR process.This way you’ll have a deep understanding of how the process should flow when having discussions with upper management and be able to defend any modifications, enhancements or complete overhauls.

Keep in mind that when speaking with management, your initial draft is just that – a draft. Be prepared to have a detailed conversation so you can understand what their expectations are and that you properly define what your incident process is providing. It’s possible that in these initial conversations you will identify areas that need to be modified or added.If this step is not accomplished correctly,it’s possible that the functions of your future IR team will not be understood or properly recognized.This could result in your process not being properly advertised to the enterprise, in which case it simply becomes just another “informal process”. Be sure to gain managements approval, communicate and advertise your new structure so that when an incident does occur, your new framework will be used.This will eliminate any overlap and ensure that the authority of the members of your future IR team remains fully recognized.

Some other questions that you may ponder along the way:

  • How far will IR processes be able to reach?
  • Who will make up the IR Team’s client base?

The first question relating to the reach of the IR process speaks to cases where critical services and applications are provided by external third parties. In these cases, you will have to decide on how far the IR process will flow and if a “hand-off” needs to occur. This needs to be explored at length since this will make your resolution process dependent on the efforts of an outside entity.

Questions like these are highly important because in the case of many enterprise environments, there are multiple areas that are critical to business operations. This brings us to the second question regarding the IR client base. This refers to subsidiaries or operating companies that, although separate, may fall under the auspices of the parent organization. You need to understand the relationship to these companies and if they provide critical applications, services and other related business functions. More than likely, these entities will also have to fall under the scope of your IR process and it will be necessary to identify key stakeholders at those locations to support your IR. This begs the question… who should form part of the Incident Response team?


Depending on what you read, you may find different titles and roles for Incident Response. The following listing is an outline of some roles and responsibilities that I used when building an IR plan at a past employer. Each environment is unique, so you will need to research your own requirements and then tailor a plan that meets your needs. Generally, the types of roles that should exist within an IR function are:

Incident Response Officer – This individual is the Incident Response champion that has ultimate accountability for the actions of the IR team and IR function. This person should be an executive level employee such as a CISO or other such corporate representatives. It would be very beneficial if this individual has direct reporting access to the CEO and is a peer of other C-level executives.

Incident Response Manager – This person is the individual that leads the efforts of the IR team and coordinates activities between all of its respective groups. Normally, this person would receive initial IR alerts and be responsible for activating the IR team and managing all parts of the IR process, from discovery, assessment, remediation and finally resolution. This individual reports to the Incident Response Officer.

Incident Response Assessment Team – This group of individuals is composed of the different areas serviced by the IR team. This allows expertise from every critical discipline to weigh in on classifications and severity decisions once an incident has been identified. It is very beneficial to have representatives from IT, Security, Application Support and other business areas. In the event of an incident, the IR Manager would gather details of the incident from the affected site, begin tracking and documentation (possibly through an internal ticket management system) and then activate the Assessment Team. This group would then discuss the details of the incident and based on their expertise and knowledge of the business, would then be able to assign an initial severity. This team reports to the IR Manager.

Remote Incident Response Coordinator – This role should be assigned to qualified and capable individuals that are located in other geographic areas. These individuals ultimately report to the Incident Response Manager but in their geographic region, they are recognized as IR leaders. This will allow these assistants to manage the efforts of local custodians during an incident. This configuration is very useful, especially for organizations that have offices in multiple time zones. If an IR Manager is located in the United States but an incident occurs in a Malaysian branch, it will be helpful to have a local security leader that is able to direct efforts and provide status updates to the Incident Manager. This way, regardless of the time zone the correct actions will be invoked promptly.

Incident Response Custodians – These individuals are the technical experts and application support representatives that would be called upon to assist in the remediation and resolution of a given incident. They report to the Incident Response Manager or to the Remote IR Coordinator(s) depending on their location(s).

Once you’ve been able to identify the proper stakeholders that will form your team, you will have to provide an action framework they’ll be able to use when carrying out their responsibilities. Think of this “action framework” as a set of training wheels that will guide your IR team. What does this mean? Let’s move on to the next section to discuss this…


A part of outlining this framework involves the identification of IR Severity Levels. These levels will help your team understand the severity of an event and will govern the team’s response. Some suggestions for these levels are the following:


Earlier in this article, I mentioned the benefit of identifying any existing informal process that your company may already be following. If so, it will now be necessary for you to step through that process mentally, keeping in mind your identified severity levels so that you can start to document each step of the process. You will undoubtedly start to remove irrelevant portions of the informal process but may opt to keep certain items in place. (For example, certain notification procedures may still be useful and you may continue to use these in your new IR process to alert members of your team). If you don’t have a starting point like this and you’re starting from scratch, then perhaps the following suggestions can provide some direction.

Start to create a documented action script that will outline your response steps so your IR Manager can follow them consistently. Your script should show steps similar to the following:

1 Incident announced
2 IR Manager alerted
3 IR Manager begins information gathering from affected site
4 IR Manager begins tracking and documentation of incident
5 IR Manager invokes Assessment Team
(Details of call bridge or other communication mechanism)
6 Assessment Team reviews details and decides on Severity Level of incident.
FOR SEVERITY LEVEL 1 – Proceed with following sequence
11.0 Determine attack vectors being used by threat
11.1 Determine network locations that are impacted
11.2 Identify areas that fall under “Parent Organization”
11.3 Identify systems or applications that are impacted
FOR SEVERITY LEVEL 2 – Proceed with following sequence
12.0 Determine attack vectors being used by threat
12.1 Alert Incident Officer to Severity 2 threat

This of course is an extremely high level example, but as you can see, it is possible to flesh out the majority of the process with specific action items for each severity level. Be sure to thoroughly research your unique environment to develop a process that fits your needs. You may have to add custom steps to cover incidents that span multiple countries and subsidiaries. Once you’ve created your may want to consider developing small wallet size scripts for the members of your Assessment Team and other key players on which you will need to depend to make this run efficiently. In this way, each member will have necessary information on hand that will allow them to respond as expected.

This article just scratches the surface of the work that is required to build a full IR process but hopefully this has given you some direction and additional areas to explore when planning your next IR project!