Self Sign

Day 19

If you're using SSL/TLS digital certificates with Connect:Direct Secure+ when connecting to your 3rd parties, you might well have a security policy that states that you will not connect with machines from 3rd parties that use self signed certificates.

You probably would prefer to connect with a 3rd party node that presents a digital certificate that is signed by someone you trust, such as VeriSign.

It might be that the history of the configuration of the Connect:Direct connection and the security policy did not coincide.

You may be in need of finding out which of your existing connections use self signed certificates.

As usual the information is within the Connect:Direct statistics, but not viewable from the "select statistics" command from  within the Connect:Direct command line.

The following function will check the statistics records piped through it to check which Secure+ connections use certificates that were signed by themselves.  In other words it checks statistics records where Secure+ was used and where the certificate issuer is the same as the subject of the server certificate used by the connection.

function selfsigncerts
{
grep RECI=CTRC | awk -F\| '
{
record["CSPE"]=""
record["CERI"]=""
record["CERT"]=""

for(i=1;i<=NF;i++)
{
key=substr($i,0,index($i,"=")-1)
value=substr($i,index($i,"=")+1)
record[key]=value
}

name = record["PNOD"] ":" record["SNOD"]

if((record["CSPE"] == "Y") && (record["CERI"] == record["CERT"]))
{
connections[name]=record["CERI"]
}
}
END{
for (name in connections)
{
print name ":" connections[name]
}
}'
}

It is used like this, assuming you are in the work directory where the statistics files are:

$ cat S20121224.001 | selfsigncerts
unx.node:OTHER.NODE:(/C=GB/L=Lincoln/O=Bank/OU=IT/CN=OTHER.NODE/emailAddress=joe.blogs@bank.co.uk/SN=12345678)

Now you know which connections use self signed certificates you can go about getting them replaced with certificates you can trust via your trusted 3rd party such as VeriSign.

Other things you could check for are the encryption algorithms used by a connection. Over time encryption algorithms lose favour as they are considered weaker than others.

Certificate signing algorithms also need checking for compliance with security policies.  For example the MD5 checksum algorithm in the past was used for signing certificates, but is considered weak, and has been shown that it can be exploited.

You may have a security policy that states you don't use certain algorithms, and you may have to demonstrate that you don't use them, and if you do, identify them for remediation.

The next few blog entries will cover these issues.

Secure IT

Day 5

There is an optional product from Sterling Commerce called Connect:Direct Secure+. Secure+ will wrap your C:D connections with SSL (Secure Sockets Layer). This will encrypt the connection using any of several cyphers and authenticate the C:D nodes using digital certificates.

OK that sounds great, but why would you want to do that? The answer to that question is well it depends. SSL gives you confidentiality as the connection is encrypted. It gives you authentication as you can verify if the other node’s digital certificate was issued by someone you trust such as VeriSign etc.

Even if you believed that the information you were sending to another node was in the public domain such as your company’s share price, you would still like to be sure that the information had not been modified/falsified and that it came from the correct source and was being sent to whom you intended. This is even more important if the transfer is going over a network you do not control such as the internet.

Even in the case where the transfers are occurring on your internal network you might still use these measures. Some information is very sensitive that you do not want your IT support staff prying into such personal information like salaries etc. In this case you may want to encrypt the data on the file system using something like PGP (Pretty Good Privacy et al).

OK so you have sensitive information that is encrypted on the file system, so you might think you do not need to encrypt the connections between C:D nodes. Even in this case you might still employ Secure+ as you wouldn’t want to receive any PGP’d file from anywhere and forward it onward blindly.

PGP’d files are normally encrypted by the application that produced them and only intended for the target application to decrypt. This is done by exchanging the PGP public keys and adding them to the two endpoint’s “key rings”. That way the sender encrypts with the public key he was given earlier by the receiver, and the receiving application can decrypt with his secret key.

Once a connection between two C:D nodes has been set up, many files of differing data classifications (public, confidential, secret etc.) may flow over that connection. Some of the files will be PGP’d or encrypted prior to transfer, some of the files will not need to have the same level of protection.

You would hate to set up a connection with Secure+ using certificates for authentication and using a null cypher (no encryption) only to find that some time later someone started sending sensitive information in the clear which may be seen by someone monitoring the network.

In my view it is so easy to set up a secure connection between C:D nodes using Secure+ with authentication, encryption and the assurance the data hasn’t been modified, and know that you are not only protecting your data, and potentially your company’s reputation, but also complying with any information security standards or audit regulations you have to comply with.

You should protect your production data as a minimum, and always use Secure+ when using an un-secure network such as the internet or a network you do not have control over.

In short I always set up connections with Secure+.