+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

IBM i Customers Lag the Industry When It Comes to Encryption

Posted by Patrick Townsend on Dec 4, 2017 11:29:40 AM

This year we undertook a survey of organizations to determine how well they are doing in deploying encryption to protect sensitive digital assets. We were curious to see the level of progress organizations were making on this core part of a defense in depth strategy. Because we have information about both IBM i and non-IBM i users, we also wanted to see if there were differences based on the platform they used for their critical applications.

IBM i Encryption with FieldProcWe received responses from over 300 technology users. We felt it was a large enough response to allow us to make some generalizations.

The results were shocking.

Approximately 80 percent of our Windows and Linux respondents had taken some concrete steps to implement encryption to protect sensitive data. In most cases they still had a ways to go to fully protect sensitive data, but that was a lot more progress than I would have imagined. We did not try to distinguish between the particular database in use to store data, but we know that it spanned commercial databases (SQL Server, Oracle, etc.) and open source databases such as MySQL, MongoDB and others.

More Windows and Linux users had made progress with encryption than I would have guessed (sorry).

The real shocker was how few IBM i organizations had made steps to deploy encryption. Only about 6 percent of IBM i users had made any progress in deploying encryption as a part of their security defense in depth. And many of these IBM i users said that they had no plans at all to use encryption for security.

My surprise arises from the fact that I think of IBM i users as generally being more diligent and deliberate around sound system management and security practices. But clearly this is not the case. So what could explain this lapse on the part of IBM i users?

We have some comment data from the survey that points to a general view that IBM i users think their systems are more secure than other platforms. This view is probably a result of IBM’s early investment in security on the platform, and historical messaging about this. Of course we know now that the IBM i platform is subject to data breaches in the same ways that Windows and Linux are, but I believe that this outdated view of the security of the platform now works against IBM i users and leads directly to avoidable data breaches.

Unfortunately, I think there is another source for this lag in security by IBM i customers. There are still too many IBM employees and IBM consultants carrying the message to customers that their systems are more secure than they actually are. I even read a recent comment by a senior IBM engineer that IBM customers should not give much attention to encryption of data on their systems. They should, instead, put more attention on access controls and system security.

This unfortunate message and the myth that the IBM i platform is so secure that you don’t need to worry about encryption is still an unfortunate reality in this community. We know that IBM i users have lost data in breaches. We know that the IBM i server can be breached through weaknesses and vulnerabilities in adjoining networked PCs and servers using classic hacking techniques. A poor implementation of a defense in depth strategy leaves IBM i customers exposed. Because the IBM i server often hosts many back-office applications with rich sources of sensitive data, it is an especially egregious lapse of security.

As a community, IBM i users must do better in deploying a proper defense in depth for their sensitive data. And hopefully thought-leaders inside IBM and outside IBM will recognize the danger of overstating the platform’s native security.

Patrick

Top 5 Encryption Myths for IBM i Users

Topics: IBM i, FIELDPROC

Press Release: MongoDB, Townsend Security Announce Certified Encryption Key Management

Posted by Luke Probasco on Nov 16, 2017 9:11:00 AM

Townsend Security, a MongoDB Technology Partner, achieves MongoDB Enterprise Certification for Alliance Key Manager.

mdb-enterprise-certified-technology-partner_300x660.pngToday Townsend Security, a leading authority in data privacy solutions, and MongoDB, the database for modern applications, today announced Alliance Key Manager has certified against MongoDB Enterprise.

MongoDB Enterprise simplifies data protection by providing native encryption of data at rest. When coupled with Townsend Security’s flagship encryption key management solution, Alliance Key Manager, meeting compliance (PCI DSS, HIPAA, etc.) and security standards is even easier and more affordable for large as well as small organizations.      

By centralizing the secure storage of encryption keys and governance with a FIPS 140-2 compliant solution, MongoDB users can easily generate a master encryption key and begin encrypting database keys using native command line operations with Alliance Key Manager.

Alliance Key Manager for MongoDB gives organizations control of key management in a convenient and fast deployment option. With this joint solution it is simple for customers to encrypt their data in MongoDB Enterprise,” said Davi Ottenheimer, Product Security, MongoDB.

Encryption and key management have become a critical aspect of security and compliance management. Protecting encryption keys mitigates the risk of data breaches and cyber-attacks, as well as protects an organization’s brand, reputation and credibility. Alliance Key Manager addresses these needs by helping enterprises reduce risk, support business continuity, and demonstrate compliance with regulations like PCI DSS, HIPAA, GDPR, etc. 

“In the wake of some of the largest data breaches ever, data security is a top concern for businesses large and small. MongoDB has made it easier than ever for enterprises to secure private data with encryption and key management,” said Patrick Townsend, Founder & CEO, Townsend Security. “With Alliance Key Manager for MongoDB, MongoDB Enterprise customers have access to cost-effective, simplified encryption key management.”

Alliance Key Manager supports seamless migration and hybrid implementations, using the same FIPS 140-2 compliant technology. MongoDB users can deploy Alliance Key Manager as a hardware security module (HSM), VMware instance, or cloud-native Amazon Web Services (AWS) EC2 instance or Microsoft Azure virtual machine. Additionally, Alliance Key Manager supports hybrid and cross-cloud deployments. The solution is available for a free 30-day evaluation.

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption Key Management, MongoDB, Press Release

Press Release: Alliance Two Factor Authentication Gets Twilio SMS Text Delivery

Posted by Luke Probasco on Nov 7, 2017 11:11:00 AM

With mobile-based two factor authentication, Townsend Security offers customers an additional control to protect core security solutions from un-authorized access due to compromised credentials.

IBM i Security: Event Logging & Active MonitoringToday Townsend Security announces that its flagship Alliance Two Factor Authentication solution for the IBM i (AS/400, iSeries) has been enhanced to support SMS text delivery using the Twilio global cloud communications platform. Twilio’s self-service SMS text delivery platform makes it easy and affordable for customers to provision accounts under a SaaS model. IBM i customers only pay for what they use and can easily expand their use of the service over time.

“IBM i customers want security solutions that are affordable, easy to install, and easy to configure and administer. Our Alliance Two Factor Authentication solution requires no hardware or back-end internal infrastructure to deploy,” said Patrick Townsend, CEO of Townsend Security.

Two factor authentication is now a critical security control that every IBM i customer should be using to control access by highly privileged users. Customers can install Alliance Two Factor Authentication, provision the Twilio service online, and start using two factor authentication very quickly. The software will even identify your privileged users and help immediately enforce two factor authentication. The solution can be downloaded from www.townsendsecurity.com and includes a free 30-day evaluation.

“Many compliance regulations such as the PCI Data Security Standard (PCI-DSS) and others require or strongly recommend the use of two factor authentication (also called multi-factor authentication) to secure all non-console administrative access and all remote access regardless of privileges to core servers. A single IBM i server is often host to a large number of sensitive applications. It is common that IBM i customers run human resources, CRM, ERP and other applications on a small number of IBM i servers that then become a target for cyber criminals. The use of two factor authentication to protect highly privileged users is a security best practice. And it is now very easy to implement,” continued Townsend.

In addition to protecting the logins of highly privileged users, the Alliance Two Factor Authentication product also exposes a command interface to the Twilio SMS text service. This means that IBM i customers can now integrate SMS text authentication directly into their own applications. Need an out-of-band authentication for that multi-million dollar financial transaction? You can now do that directly from your business applications with the Send Text Message with Twilio (SNDTXTTWI) command and application program interfaces (APIs).

In addition to user authentication the new SMS text application support can be used for notification of significant application events. Your business applications can send a message when inventory runs low at a distribution center, when a business process has been delayed, or for any other critical business process. You can even embed links into the text messages to help users quickly solve problems and accomplish critical tasks.

Alliance Two Factor Authentication is licensed on a per logical partition (LPAR) basis, with perpetual and subscription licensing options available. Existing Alliance Two Factor Authentication customers on a current maintenance contract can upgrade to the new version at no charge.

IBM i

Topics: Alliance Two Factor Authentication, Press Release

Case Study: The Seed Company

Posted by Luke Probasco on Nov 6, 2017 10:32:47 AM

SeedCompany_Primary_Tag.pngSecuring Data in MongoDB Enterprise with Alliance Key Manager


“When choosing a key management solution, it needed to be 1) KMIP compliant and 2) affordable. Alliance Key Manager was both..”

- Jonathan Ganucheau, System Architect

 
The Seed Company

The Seed Company Case studyFounded in 1993 by Wycliffe Bible Translators Inc., Seed Company became one of the fastest growing Bible translation organizations by developing innovative ways to more rapidly, efficiently and accurately translate Scripture for groups who don’t have it in their language.

Over a billion people worldwide don’t have the full Bible in the language they know best. More than 1,600 languages don’t have any Scripture at all. Seed Company’s goal is zero languages without Scripture by 2025. In this generation, the Bible will become available to all for church planting, evangelism and discipleship efforts led by the local Church.

The Challenge: Protecting Private Data in MongoDB with Encryption & Key Management

As Seed Company began to outgrow its on-premise data center, it knew that in order to transition services into the cloud, the security team needed to assure business leaders and partners that their data in the cloud would be safe. To meet internal security requirements, not only did the solution need to be cloud based, but encryption needed to live in a secondary cloud provider. By taking a hybrid cloud approach and deploying a service in a secondary cloud provider, Seed Company could securely manage encryption keys and protect data stored in MongoDB Enterprise.

While compliance wasn’t a requirement, meeting security best practices to protect the contact data for partners in the field was. With identities of partners in violent, oppressive countries at stake, a breach could literally mean the difference between life and death.

The Solution

Alliance Key Manager

Seed Company’s adoption of the cloud was reliant on the ability to adequately protect private data. Alliance Key Manager was essential to their transition. “After two months of discovery, we looked at all of the cloud encryption key management vendors and compared everything from features to price,” said Jonathan Ganucheau, System Architect. “Alliance Key Manager met all of our criteria - with KMIP compliance and affordability leading our decision.”

“If someone was able to hack into our primary cloud platform and extract our backups, they still wouldn’t be able to get the actual data because the key manager is in a secondary cloud provider. This provides us with another level of hardening,” continued Ganucheau.

By deploying Alliance Key Manager, Seed Company was able to meet their organization’s needs to protect partner data in MongoDB in the cloud.

Integration with MongoDB Enterprise

“Having invested in MongoDB Enterprise with KMIP encryption, there was no need to buy competing encryption solutions, adding to the overall expense of the project,” said Ganucheau. With a low total cost of ownership, Alliance Key Manager customers can leverage the built-in encryption engine in MongoDB, with no limits imposed to the number of servers or data that can be protected.

“During discovery, one thing that came as a surprise to us was the number of vendors who claimed to support KMIP, but actually didn’t. They maybe started with KMIP compliance, but then deviated off course and no longer met our requirement of being a true KMIP service,” continued Ganucheau.

With no client software to install, Alliance Key Manager offers unparalleled security, flexibility, and affordability for all users of MongoDB Enterprise.

Reliability

One of the top concerns organizations have when encrypting data is losing access to encryption keys. Alliance Key Manager mirrors keys between multiple load-balanced servers over a secure and mutually authenticated TLS connection for hot backup and disaster recovery support. “Uptime is critical for our organization. Alliance Key Manager has remained up 100% over the past year, which is a big deal for our organization. Set it and forget it. It just works,” finished Ganucheau.

“Between your cost structure and reliability, Alliance Key Manager has earned my highest recommendation.”

The Seed Company Case Study

 

Topics: Alliance Key Manager, Case Study, MongoDB

MongoDB San Francisco local conference a big success

Posted by Patrick Townsend on Oct 21, 2017 12:50:03 PM

I just got back from the first MongoDB regional conference in San Francisco and wanted to share a few impressions. I will be blogging more about MongoDB, but here are some first impressions from the conference:

Introduction to Encrypting Data in MongoDBWe’ve had support for MongoDB encryption key management for some months now, and the conference in San Francisco last week was a real delight. This is an amazing community of developers and users who are innovating and creating new applications based on MongoDB at a rapid pace. I was happy to give the security session on encryption key management for MongoDB and it was a great success. You can find a replay here.

I spent time talking to some of the hundreds of attendees and learned a lot about how the use MongoDB. Here are just a few take-aways:

MongoDB is Easy to Use

Database development has the reputation of being difficult and requiring extensive expertise. But I met a lot of people who have developed MongoDB databases without much or any database administrative knowledge. For example, I talked to a young scientist (that was the title on her badge) who was not in an IT group at all. She had developed a MongoDB database to store and analyze genetics information from her genome sequencing project. I met a pair of IT administrators from a property management company who had developed three applications on MongoDB because their development team had a long backlog of projects. They were in the network administration group and did not have formal experience with database development, but they built applications in a short period of time. It’s truly amazing to see sophisticated applications being developed by users!

MongoDB is Replacing Traditional Relational Databases

Before last week I thought of MongoDB as a big data repository for documents and IoT data. It is that, but it is a lot more. Many of the professionals I talked to at the conference were using MongoDB the way you would use a normal relational database like SQL Server, Oracle, DB2 or MySQL. I had the definite sense that MongoDB has found a way to bridge the worlds of relational databases and unstructured big data repositories. MongoDB users told me that the APIs and toolsets let them do almost anything they wanted to do.

MongoDB Really Scales for Big Data Needs

Well, MongoDB really is a great repository for big data. I talked to a number of larger enterprises from the San Francisco Bay Area who are storing extremely large amounts of data in MongoDB databases. Medical, IoT sensor data, financial data, customer service data and other types of data from a variety of data sources are being collected in MongoDB for business operations support and business analytics. The scalability of MongoDB is truly impressive.

Sensitive Data is Going into Almost All MongoDB Databases!!!

The other thing I learned is that an awful lot of sensitive data is being stored in MongoDB. The database is very flexible, and so there tend to be a lot of data feeds into the database. And those database feeds can include sensitive data that the MongoDB developers do not know about. I heard stories about MongoDB developers being surprised to find credit card numbers, social security numbers, email addresses, medical data and a lot of personally identifiable information (PII) being stored in the database.

MongoDB developers are really aware of the risks of sensitive data in the database. And they were hungry for information on how to protect it. Fortunately MongoDB Enterprise makes it incredibly easy to implement encryption and key management. In my session I was able to show how you can enable encryption in MongoDB with just a few commands. Customers upgrading from the open source Community Edition of MongoDB get access to this encryption facility and it is a delight.

MongoDB is Doing Encryption and Key Management Right

I’ve been impressed with the MongoDB implementation of encryption and key management from the start. First, MongoDB stepped up and implemented encryption right in the MongoDB database. There is no need for any third party file or folder encryption product to sit under the database. The encryption in MongoDB is based on industry standards (256-bit AES) and is tuned for performance. This is exactly what you want - your database vendor taking responsibility for encryption and owning the performance profile.

MongoDB also got the encryption key management part right. They based the key management interface on the open OASIS standard Key Management Interoperability Protocol (KMIP) in order to immediately support a broader community of key management vendors. That made it easier for us to certify our key management solution, Alliance Key Manager, for the MongoDB Enterprise platform. We are happy to support both Intel and POWER chip architectures for MongoDB deployments.

Lastly, just a personal note. I met a lot of MongoDB staff and managers at the conference. What a great bunch of people. They were energized and positive about what they are doing. Every company has its own character, and I found myself happy that we were engaged with this group of people.

Patrick

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

Fundamentals of MongoDB Encryption Key Management

Posted by Liz Townsend on Oct 10, 2017 9:11:00 AM

Encryption key management is the cornerstone of an effective encryption strategy. Without key management, encryption stands alone as only half of a solution. When you leave the keys to unlock your sensitive business and customer data exposed, then you expose your entire organization to the risk of data loss or theft. Luckily, MongoDB was born in the age of modern data security and developed their no-SQL database with the forethought and insight to incorporate strong encryption and key management solutions. This means that today, with MongoDB Enterprise, MongoDB customers can meet encryption and key management best practices fairly easily through implementing native encryption and deploying a third-party enterprise key management solution.

Introduction to Encrypting Data in MongoDBIn order to enable customers to seamlessly implement enterprise encryption key management, MongoDB integrated a universal encryption key management protocol called the Key Management Interoperability Protocol (KMIP). Unlike many other legacy databases who have floundered over the years trying to help customers do strong key management, MongoDB enables customers to protect encryption keys out of the door with a number of tested and validated enterprise key management partners. To know if you’re encryption key management solution is compatible with MongoDB, check to see that it has implemented KMIP.

What is Enterprise Encryption Key Management?

Enterprise encryption key management includes both technological and policy-based controls that integrate to provide the highest level of security of an organization’s encryption keys. Both types of controls are important to protecting encryption keys.

On a technological and physical level, encryption keys should be stored in a logically or physically separate hardware or virtual key server, dedicated to performing key generation, storage, and distribution. Keys should be generated with a FIPS 104-2 validated pseudo-random number generator and stored in a secure key database. Keys used for encrypting data (data encryption keys, or DEKs) should be key-wrapped and encrypted using key encryption keys (KEKs)--these keys are only used to encrypt DEKs inside the secure key database.

Once encryption keys are generated and in use, they should be distributed for use over a secure Transport Layer Security (TLS) session using certificates to authenticate the user requesting the encryption key. An enterprise key management server should use the most recent, recommended version TLS--1.2--as vulnerabilities were discovered in TLS 1.1 and TLS 1.0.

Lastly, enterprise key managers should perform real-time backup and high availability functions to prevent downtime and ensure business continuity. This means that each key server should perform active-active mirroring to one or more high availability server as well as perform routine, automated backups to secure storage drives.

All of these functions are critical to meeting best practices and securing encryption keys. However, beyond the technology, an enterprise key manager should implement user rules and administrative options that enforce particular policies and policy-based best practices.

Encryption Key LifecycleA critical administrative component to encryption key management is the ability to manage the complete encryption key life cycle. The encryption key lifecycle is defined by the National Institute of Standards and Technology (NIST), which outlines all aspects of a key’s life including key generation, pre-activation, activation, distribution, revocation, post-activation, backup, and deletion.

The administrative console that allows access to these functions should also give the IT or security administrator the option to designate key users or user groups as well as set keys to automatically rotate after a certain number of days, months, or years. This is just one requirement for organizations who fall under security standards for some regulated industries such as the payment card industry. The Payment Card Industry Data Security Standard (PCI DSS) outlines key management requirements for card holders or processors that can typically only be met using an enterprise-level encryption key management solution.

To learn more about PCI-DSS and encryption key management, view this webinar.

Beyond managing the key lifecycle, an enterprise key manager should actively audit and log all activity and functions performed on the key management server and record these logs to an external event monitoring or logging server so that malicious activity can be detected in real time. Your key management solution should be compatible with common event monitoring solutions and export logs in standardized formats in real time.

Lastly, your key management solution should inherently enforce policy-based security functions that meet key management best practices such as separation of duties and dual control. Separation of duties ensures that no single person is in control of multiple key management procedures such as the client request and subsequent distribution of an encryption key. The person requesting the key and the person distributing the key should be two different people. Dual control prevents any key management process to be controlled by a single person; for example, two security administrators should be needed to authenticate access to the key server. While these policy-based controls are sometimes optional, they should always be available and easy to implement in your encryption key management solution.

MongoDB Likes Centralized Key Management

When MongoDB decided to implement KMIP, the decision was likely a deliberate strategy to help users to either leverage the enterprise key management solution they already have, or to use common key management solutions that are KMIP-compatible. The power of KMIP is that it enables users to truly achieve centralized key management. A historical problem surrounding key management was the difficulty of an organization to store and manage encryption keys across multiple platforms, operating systems, and often departments. By implementing KMIP, MongoDB continues to make implementing key management across an organization more and more easy and effective, and therefore more user-friendly, which is what MongoDB is best known for.

Without deploying a strong encryption key management solution, encryption of sensitive data on its own is considered ineffective. In the age of the cloud, deploying a key management solution alongside your data is equally important, and therefore having options for where you deploy it is an important factor in your key management strategy. An effective key management solution should not only be centralized across your organization, but it should meet your data where it’s at, whether that is the cloud, a virtual environment, or on-site hardware.

KMIP also enables MongoDB customers to choose their own KMIP compliant key management solution and maintain complete custody of the key management server, and therefore the keys. Whether deploying the key manager in the cloud, in a virtual environment, or on-site, owning a third-party KMIP compliant key manager allows users to retain total control of their keys without sharing access with cloud service provides or software vendors.

Lastly, when researching professional or enterprise key management solutions, check to see if the vendor has validated their solutions with NIST such as to the NIST FIPS 140-2 standard, uses standardized technology, and has been validated to meet PCI DSS or other regulatory certifications. These validations ensure that the technology has been tested by independent labs to the highest security standards.

In combination with a robust database encryption solution from MongoDB, your encryption key management solution will elevate your security position and total level of control.

Introduction to Encrypting Data in MongoDB

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

HIPAA and Encryption - What You Need to Know

Posted by Patrick Townsend on Oct 10, 2017 8:46:26 AM

HIPAA regulations regarding data security for patients are hard for a layperson to understand, and are even difficult for administrators and technologists who work in the healthcare industry. This is especially true for smaller organizations, partly due to the complexity of the HIPAA law itself, and the HITECH regulations that followed it. Let’s try to clear up some of the misunderstanding around HIPAA and encryption, and clarify what you should do regarding data protection for patient data.

Achieve saThe first confusion about the protection of patient data is that encryption of this data is a strong recommendation, but that it is not a mandate. It is what is termed an “addressable” requirement. The word “addressable” has very specific meaning in the context of HIPAA. If implementing encryption of patient data is not feasible, a healthcare organization under HIPAA regulations, can implement equivalent protections. So, if your software vendor or IT department thinks that encryption is not feasible you have the option to implement other equivalent security controls to compensate for that. The reasons why you think it is not feasible must be documented in writing, and must be reasonable and valid.

Encryption is not a mandate under HIPAA law. And unless the law changes, it is probably not possible for HHS and its Office for Civil Rights (OCR) to make it mandatory.

But there is much more that you need to know. While HHS and OCR cannot mandate the encryption of patient data, they do have the ability to make it painful if you don’t. And that is exactly what they are doing. For example, if you claim that you can’t encrypt patient data, document your reasons, implement compensating controls, and THEN have a data breach, you are likely to be penalized for the lack of effectiveness of the compensating controls. Your data breach is clear evidence that your compensating controls were inadequate.

I like to call this a “Backdoor encryption requirement”. That is, there is probably nothing you can do in the way of compensating controls that are equivalent to encryption. But you won’t discover that until you have a data breach.

Lacking the ability to mandate encryption, HHS and OCR have taken to the strategy of increasing the penalties for lost patient data. I’ve heard recently from many organizations in the healthcare segment of increasing concern about the potential fines related to a data breach. This is driving a new interest in encryption and the related requirement to protect encryption keys.

This last point is crucial when implementing encryption for HIPAA compliance - your encryption strategy is only as good as your encryption key management strategy. Encryption keys are the secret that has to be protected. If you lose the encryption key, the cybercriminals have the ability to access patient data. Storing encryption keys in a file, in application code, or on mountable drives or USB storage will certainly fail a best practices review. Use a professional, certified key management solution in your encryption deployment to protect patient data.

If you are going to do encryption of patient data, get it right the first time! Use good key management practices.

Patrick

Achieve Safe-Harbor Status from HIPAA Breach Notification

Topics: Encryption Key Management, HIPAA, AES Encryption

Alliance LogAgent, ServiceNow and your IBM i

Posted by Patrick Townsend on Oct 2, 2017 9:47:13 AM

Most IBM i customers struggle to provide more IT services to their organizations with an ever-shrinking set of budget and human resources. It is natural, then, that IBM i customers would look to a variety of automation and management tools to buttress their existing IT service infrastructure. IT Service Management (ITSM) tools are a great place to start.

Automatically collect and transmit system security eventsThe clear leader in ITSM is ServiceNow. ServiceNow is the Gartner Magic Quadrant leader in ITSM with more than double the market share of its closest competitor. It is easy to see why - building on its IT Service Support Management (ITSSM) tools ServiceNow has had a singular focus on the IT service management space for some time. It has a well-designed interface that makes integration with other platforms easy, and it deploys as a web-based SaaS solution. It is easy to start with Incident management and add a wide set of automation and service features. You can find a good overview here.

Here at Townsend Security we have been looking at ways of making life easier for our IBM i customers and especially IT management and Security Administrator professionals. Integrating ServiceNow with our Alliance LogAgent solution was a natural step. With a handful of customers cheering us on, we committed to ServiceNow integration and providing an open path for ServiceNow integration outside of our SIEM integration product. Our first steps focused on some critical IT and security areas.

Administrative User Access

Security professionals understand how critical it is to control and monitor administrative access to the core business systems. Administrative user access to an IBM i server should be rare and well-controlled. Cyber-criminals attempt to gain administrative privileges in order to steal sensitive data or cause havoc. Monitoring administrative user access to your IBM i is now a critical security requirement.

Alliance LogAgent can now automatically and in real time create a ServiceNow incident when a highly privileged administrator logs onto your IBM i server. This notification to ServiceNow leverages our earlier enhancements that dynamically identify a high level of privilege including those privileges inherited from Group and Supplemental profiles. Your IT security team can react quickly to unexpected administrator access. Of course, fully reporting to your SIEM solution is included.

Disabled User Profiles

IBM i users have implemented strong password controls to strengthen system security. Unfortunately this means more IT support for users who forget their password and disable their user profile. Wouldn’t it be great to get a real-time notification when a user profile is disabled? You can now do that with Alliance LogAgent. A disabled user profile will generate a ServiceNow incident record and your IT support team can pro-actively reach out to help your user. An additional security benefit is that you can detect automated attacks on your IBM i servers that result in a number of disabled user profiles.

Library and IFS Object Changes

Attackers often attempt to modify applications and configuration files as a part of an attempted breach of your system. This might include access to application configuration files and programs in a library, or it might be an attempt to modify a web configuration file in the IFS file system. Alliance LogAgent now allows you to selectively report these object and file changes to ServiceNow in real time.

ServiceNow User and Application Integration

I’m leaving the best for last! In addition to the automatic events that Alliance LogAgent raises as a ServiceNow incident, there is also a new command that lets you integrate ServiceNow into any application on your IBM i server. The new Create ServiceNow Incident (CRTSVNINC) command gives you the ability to create ServiceNow incidents from your own applications.

Is an ACH payment over the usual limit being initiated?

Log it to ServiceNow.

Is a mortgage loan being originated that violates bank policy?

Log it to ServiceNow.

Has a credit card transaction been refused due to fraud?

Log it to ServiceNow!!!

I’m sure you get the idea. Automating these types of events are now fully under your control.

If you already have a SIEM integration tool or notification system, don’t despair.Alliance LogAgent can co-exist with existing tools from third-party vendors. And you can use the new ServiceNow integration command without using the SIEM and system logging components of Alliance LogAgent. Of course, if you want to upgrade to a more advanced tool you should contact us. There’s a great competitive upgrade plan waiting for you.

The IBM i server is a great platform and we are fully committed to providing leading-edge enhancements to our IBM i solutions. You will be hearing more from us about new innovations for the IBM i in the days and weeks ahead.

Patrick

Automatically collect and transmit system security events

Topics: Alliance LogAgent, ServiceNow

The TNT/FedEx NotPetya Breach and Why Old Style Backups are Back in Fashion

Posted by Patrick Townsend on Sep 25, 2017 9:09:23 AM

Not all cyber attacks result in the loss of sensitive data. The astounding Equifax data breach is on all of our minds right now, but sometimes a security breach results in unrecoverable damage to critical systems. These attackers are not looking to perpetrate financial fraud - they are looking to damage the operational status or reputation of an organization. That happened to TNT (a FedEx division) recently.

data-encryption.jpgTNT/FedEx suffered the loss of critical systems that inflicted severe financial pain. John Pescatore of SANS expressed it this way:

When numbers like this come out, they are great data for convincing your management that, almost invariably, fixing known security problems (even if it causes business disruption) is almost invariably cheaper than enduring an incident. FedEx acquired TNT Express in 2016 fort $4.4B, and the estimates for TNT's 2016 profit were about $150M. So, NotPetya essentially cost FedEx *two years* of TNT's profit. Even if mitigating the Windows SMB vulnerability back in March would have required TNT to shut down all revenue operations for an entire day, the impact would have been about $7M in revenue or in the range of $350K in profit, or about .1% of what enduring NotPetya has cost, so far.”

At Townsend Security we usually focus on encryption technologies to help prevent the loss of sensitive data. But it is good to remember that the loss may be in critical IT infrastructure.

How to recover from that?

You need to have current backups of all critical systems. Yep, old fashioned, off-line backups that cannot be damaged by the attacker. Too many modern backup systems are based on shared storage that appear as mounted drives. These are very easy to damage by a NotPetya or similar attack. It seems old-fashioned, but you really need to have backups on removable media in a safe location. There is just no substitute for that.

Of course, the tape backup should be encrypted to protect the data on the way to offsite storage, in storage, and on the way back. Tape backup systems are very inexpensive these days. We happen to like the system from Quantum, who are one of our partners on the encryption key management front. But you can find good solutions from a number of vendors. More information about Quantum here.

Patrick

Topics: AES Encryption

Alliance LogAgent for IBM i Integrates with ServiceNow

Posted by Luke Probasco on Sep 19, 2017 12:12:00 AM

Alliance LogAgent for IBM i now instantly records critical system events and integrates line-of-business applications with ServiceNow, the leading cloud-based solution for IT systems to instantly record critical system events.

Townsend Security today announced support for integration of IBM i servers and applications with ServiceNow, the leading cloud-based solution for IT system support problem tracking and resolution. Leveraging the ServiceNow REST web interface, Townsend Security’s Alliance LogAgent solution can now instantly record critical system events as ServiceNow Incident reports. Additionally, Alliance LogAgent also exposes an API command to allow IBM i customers the ability to integrate line-of-business applications with ServiceNow. When business applications encounter critical events or errors, these can be immediately visible to the IT administrative and security teams for rapid response and resolution.

“IBM i customers want to leverage the best of the new generation cloud-based service offerings. This new release of Alliance LogAgent gives them that ability right out of the box. Existing ServiceNow customers have all they need to record critical incidents in real time. IBM i users who are not currently ServiceNow customers can rapidly subscribe to ServiceNow and start enjoying the benefits of this leading IT Systems Service Management (ITSSM) solution,” said Patrick Townsend, CEO of Townsend Security.

“The power and stability of the IBM i system can integrate with the best of the cloud-based ITSSM solutions. It’s an easy win for IBM i customers, and those with existing system logging solutions will be happy to know that Alliance LogAgent can co-exist with existing technology, or IBM i customers can take advantage of our competitive upgrade program,” continued Townsend.

New ServiceNow features in Alliance LogAgent include:

Privileged User Access
Monitoring administrative access to IBM i servers is a critical compliance and security best practice. Alliance LogAgent can identify in real-time the privilege level of a user signing on to the system and report it to ServiceNow and to any SIEM solution. Alliance LogAgent is unique in its ability to dynamically identify the true privilege level of a user by examining the native authority of the user as well as authorities inherited from Group and Supplemental profiles. Cyber criminals often use privilege escalation as a starting point in an attack. Alliance LogAgent can now identify privileged user logons and raise a ServiceNow support incident.

User Profile Disabled
A common labor-intensive task for IT administrators is managing user accounts that are disabled due to an excessive number of password failures, or which are disabled due to a brute force attack. Alliance LogAgent will now automatically identify disabled user profiles in real-time and create a ServiceNow incident report. This gives the IBM system and security administrator rapid visibility and resolution for disabled profiles. Additional system security is provided by an out-of-band notification via ServiceNow of a potential attack in progress.

File or Object Change
An attacker often modifies a program or file on the IBM i server as a part of compromising sensitive data. For example, an attacker might modify the IBM i web server configuration file to direct users to malware on infected sites. IBM i customers can now identify both library and IFS objects for monitoring by Alliance LogAgent with reporting directly to ServiceNow. Early detection of modified programs and files can help an IBM i customer avoid a data breach.

Application Integration with ServiceNow
IBM i developers can now easily integrate business applications and processes with ServiceNow through a new command named Create ServiceNow Incident (CRTSVNINC). By embedding this command into user applications the IBM i developer can provide a wide set of incident creation capabilities. This new command builds on the ServiceNow REST interface without requiring complex communications or API logic in the business application. Using the ServiceNow command does not require the SIEM integration components of Alliance LogAgent. IBM i customers can use just the ServiceNow integration component, or combine its use with Alliance LogAgent SIEM integration.

Alliance LogAgent is licensed on a Logical Partition (LPAR) basis. Both perpetual and subscription licenses are available. Volume discounts are available. Additional charges apply to the ServiceNow application. Alliance LogAgent can be downloaded from the Townsend Security website for a free 30-day trial of the fully functional solution. ServiceNow integration requires a subscription license from ServiceNow. Trial subscriptions are available from their website at http://servicenow.com.

IBM i

Topics: Alliance LogAgent, Press Release

 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all