Name the 12 Apostles - a quiz

Because we’re coming up to Easter, I thought I’d do something different this week!

Can you name the 12 Apostles?

Well, obviously, there’s Matthew, Mark, Luke, and John, who have Gospels named after them – that’s four. Whoops, sorry, you can’t include Mark and Luke – they weren’t Apostles.

Well, from the Easter story we’re all familiar with Peter and Judas Iscariot. So that’s four we can name, we’re a third of the way there.

So who does that leave, mmmh!

There was Simon. Oh no not him because he’s already in our list – he’s also called Peter. So still eight to go.

There was Doubting Thomas – that’s five.

But who were the others. Well, there’s James who was John’s brother, and there was Andrew who was Peter’s brother – that’s seven. Just five to go.

So who are those last five? Bonus marks for anyone who remembers Bartholomew, James (the less), Philip, Simon the Canaanite, and Thaddeus.

So hang on, what about all those people who keep saying Jude – the patron saint of desperate causes. Yes he was an Apostle, but, apparently, he is also known as Thaddeus – mainly because early writers didn’t want him being confused with Judas Iscariot (hence the alternative name).

Which brings me nicely back to dealing with Judas Iscariot. Obviously he was an Apostle – one of the 12 – but you can’t imagine early Christians being too keen on including him in a list of revered Apostles! So who became the new twelfth man (if you’ll pardon a sort of cricketing metaphor)? In Acts it is said that following the death of Judas a new twelfth Apostle was appointed. He was called Matthias. He usually appears in lists of the twelve Apostles rather than the disgraced Judas Iscariot. However, some argue that only people actually sent out by Jesus could truly be called Apostles.

Troublingly, The Gospel of John also mentions an Apostle called Nathaniel (see John 1:45-51 and 21:2). Most authorities assume this is an alternative name for Bartholomew – so don’t worry about that one.

St Barnabas (who, confusingly, was originally called Joseph) is referred to as an Apostle in Acts 14:14. His claim to fame was introducing Paul (of road to Damascus fame) to the disciples in Jerusalem. And that’s the lot!

And for lots of bonus marks, can you name the thirteenth Apostle? Of course, there is more than one answer to this question.

Paul (of Tarsus) described himself as an Apostle following his Damascene conversion.

The Roman Emperor Constantine was responsible for making Christianity the official religion in Rome in the 4th century. He is often referred to as the thirteenth Apostle.

Plus, there’s also a long list of people who have brought Christianity to a some particular part of the world, who are referred to as the Apostle of somewhere or Apostle to somewhere else (for example St Augustine, the Apostle to England, or St Patrick, the Apostle to Ireland).

So, a much harder quiz than you might have thought. How many did you know?

If you celebrate it, have a good Easter next week. It’s back to mainframes in two weeks’ time.

Guest blog – Mainframe security: who needs it?

This week, for a change, I’m publishing a blog entry from Peter Goldberg, a senior solution architect at Liaison Technologies, a global provider of cloud-based integration and data management services and solutions based in Atlanta. He works directly with customers to identify their unique data security and integration challenges and helps to design solutions to suit their organizations’ requirements. A frequent speaker at industry conferences on eBusiness security issues and solutions, he can be reached at pgoldberg@liaison.com.

I’ve been helping companies on both sides of the pond solve their data security problems for many years now. If I’ve learned one thing, it’s this: when I go into an organization that runs Windows, there’s little question of the need for data security. The organization knows it and so do I. When I visit a company whose IT infrastructure revolves around a mainframe, however, the mindset is often quite the opposite. In fact, the biggest data security misconception I encounter is the belief that the mainframe environment is inherently secure. Most IT staff view the mainframe as just another network node. Why? Because it’s universally perceived as a closed environment and, therefore, invulnerable to hackers.

In some cases, it’s the mainframe IT pros who hold this conviction. In other instances, it’s the executive management team. Lack of management attention allows “bad practices” to continue. I can tell you this without reserve: data stored in mainframes needs protection just as much as sensitive information stored on a Windows server or anywhere else. And, as systems continue to support more data, users, applications, and services, effective security management in the mainframe environment becomes significantly more difficult.

News flash: mainframes can be hacked!

For that simple reason, mainframe security should not be taken for granted.

Even though the mainframe is a mature platform, there is a real shortage of mainframe-specific security skills in the market. And, the few mainframe security practitioners who are out there spend a lot of time implementing configuration and controls within their environments as well as putting into place security systems like RACF, which provide access control and auditing functionality. As for other security measures, in my experience, the mainframe people know about encryption, but they’re not terribly aware of newer data security techniques like tokenization as it relates to protecting data within the mainframe environment and beyond.

Tokenization is a data security model that substitutes surrogate values for sensitive information in business systems. A rapidly rising method for reducing corporate risk and supporting compliance with data security standards and data privacy laws, it can be used to protect cardholder information as well as Personally Identifiable Information (PII) and Protected Health Information (PHI).

In fact, for companies that need to comply with the Payment Card Industry’s Data Security Standard (PCI DSS), tokenization has been lauded for its ability to reduce the cost of compliance by taking entire systems out of scope for PCI assessments. And, even in companies that do not deal with PCI DSS or other mandates, tokenization has proven effective for managing the duplication of data across LPARs and for facilitating the usage of potentially sensitive data for development purposes.

Too often, compliance audits skim over mainframe control weaknesses and there are also fewer mainframe-specific security guidelines. But this does not mean that significant risk is not there. You can apply a risk-based, defence-in-depth approach within the mainframe environment by using stronger mainframe host security controls and by using tokenization to protect the data itself.

To beef up data security on a mainframe, here’s my advice:

1. Bring in mainframe security experts to identify and remediate risks, and to develop and enforce security policies and procedures.
2. Develop in-house capabilities and skilled professionals across the mainframe platform to support security initiatives.
3. Evaluate available security configuration and administration tools – there are some really good ones out there.
4. Apply an in-depth security strategy that includes secure access and authentication controls, and use them appropriately.
5. Adopt encryption and tokenization to protect sensitive information. Through their proper implementation, it’s really not that hard to achieve a true high level of protection within the mainframe environment.

Protecting sensitive and/or business-critical data is essential to a company’s reputation, profitability, and business objectives. In today’s global market, where business and personal information know no boundaries, traditional point solutions that protect certain devices or applications against specific risks are insufficient to provide cross-enterprise data security. Combining encryption and tokenization, along with centralized key management, as part of a corporate data protection programme works well – including in mainframe-centric environments – for protecting information while reducing corporate risk and the cost of compliance with data security mandates and data privacy laws.

Don’t be fooled: your mainframe isn’t inherently secure. Doing nothing is no longer an option!

Thanks Peter for your guest blog.
And remember, there's still time to complete the mainframe user survey or place a vendor entry in the Arcati Mainframe Yearbook 2012.