How to NOT be safe when you walk home alone

The Companion Safety App has been getting some coverage in online media, mostly positive, in the last few days. The advertisement for Companion shows two girls separately asking to be “accompanied” on their walks to their destinations. Their “companions” are people who are following their friends’ progresses on their phones from the comfort of their homes.

What should you do if you find yourself walking alone at night and feel unsafe? Here are some tips. Walk quickly to the nearest place where you will be safe. Be aware of your surroundings. Do not present an easy target. Be ready to run. If the situation is really desperate, prepare to fight. Whatever you do, do not pick up your phone and let yourself be distracted from your surroundings. That is precisely what the Companion Safety App will tempt you to do.

Consider the two girls in the advertisement. The first one holds on to her phone after she “gets” her companion. The second actively plays with her phone and dumbwalks despite the fact that she needs accompaniment.

When you are in danger, what is most important is to immediately protect yourself. One should not allow oneself to a false sense of security merely on account of a virtual companion. There is a distinction between being safe and feeling safe. The Companion Safety App causes users to opt for the latter instead of the former.

The horror of the security product presentation

“Attackers can get in within seconds.” “Data can be extracted within minutes.”

If you are in IT (especially if you manage IT), chances are that you have sat through a security product sales presentation. It contains scare stories of vulnerabilities and attackers and tells you about just the product to solve the problem.

It starts with a few recent headlines. There will typically be one about a security breach that lost a company many credit card numbers belonging to its clients. This might be followed by another headline that talks about lost social security numbers or other personal information. (5 minutes)

Step 2 is the scariness of the task of the IT team. There are plenty of vulnerabilities that any IT infrastructure may have. The ante is quickly upped to introduce “zero-day” – vulnerabilities that are only known to the attacker and not even to the vendor who created the security products that are in use. The scares are further escalated to show how quickly data can be extracted and for how long the attackers can remain in your network before they are typically detected. (5 – 10 minutes)

Then comes the question. What can we do about this? The answer immediately follows. “We need something that … does A, B, C and D!” (1 minute, typically just one slide)

The big reveal that we have been waiting for! Introducing PRODUCT!!!  (5 minutes)

An explanation follows as to how A, B, C and D are done by the product. There is an additional explanation as to why no other product compares (20 – 30 minutes).

What is shameful about the aforementioned presentations is the amount of time that they waste in an attempt to scare people into buying a product. Not only that, the security product is presented as the necessary solution that will fix the problems that none of your existing products could fix.

No security product will secure your IT infrastructure by itself. See this previous post that I made for more information. There are plenty of situations where the existing products in one’s infrastructure, effectively used, can provide the level of security that is required by management. A direct question to the salesperson as to the measurable effectiveness of the product will always be met with caution. One would just not expect it, coming so soon after the wonders of the newly introduced product.

Security devices need to keep one-upping each other. So do security sales pitches. Perhaps a good way to improve them would be to not waste the customer’s time and patience attempting to scare them.

My Telco Knows My Ethnicity. Should it?

I received something in the mail in April that caused me some irritation. It was a colourful card wishing me a “joyous new year” – in April. It turns out that various Indian and Indian-derived new years are celebrated in April. Inside, the card contained information about some celebratory programme.

Why would this card irritate me? In just the preceding few months, Christmas, New Year and Chinese New Year had passed without me getting any card. Somehow my telco found out my ethnicity and sent me a card that it figured was tailored to my interests (It wasn’t. I have no idea who those people in the pictures are).

How they figured it out is not a difficult question. Telcos in Singapore (and in many other countries) collect copies of one’s identity card perhaps mandated by law, and also to identify the customer during customer interactions. Singapore’s identity cards (ICs) clearly state the person’s race. My guess is that someone at the telco thought it a good idea to collect the personal information about ethnicity for some tailored marketing. It couldn’t hurt, right? After all it already holds on to the information. Not so.

Singapore enacted a personal data protection act (PDPA) a few years ago. One key idea of the law is that personally identifiable information (such as the information in one’s IC) should only be collected with consent for a stated purpose (such as identifying a person when he calls up the telco claiming to be a customer). Getting promotional material from the company about non-telephone services was not something that I had signed up for.

I exchanged a few emails with the telco’s data protection office. I was advised thus:

“We are using the individual’s ethnicity/race to ensure that we do not send offers/events that are not relevant or potentially offensive to the customer.”

I found this to be objectionable even on some non-privacy grounds but what I found really problematic was how they ended that email.

“If you could share the reason of why you would not consent to giving this information, it will be helpful for us to see how we can best address your concerns.”

The telco took for granted that I was giving up this information and I would be OK with them using it for the purposes they chose. Without asking me.

In the very last email, the DPO assured me that the telco would not provide my data to third parties for commercial purposes without seeking my explicit permission. I had no such worries. My concern was that they would abuse it internally for commercial purposes without asking my explicit permission, as they already had.

Companies can try to wiggle out of their responsibilities by finding loopholes with the law. My ethnicity is not really the personally identifying information (PII) that is the focus of the PDPA. The problem lies in the fact that it is collected from the IC, that treasure trove of PII and we have no visibility as to what else the company is doing with our information.

The PDPA was a step in the right direction for Singapore. Many companies have scrambled to follow the letter of the law in terms of visible implementation. They have put up notices on their websites stating who customers can contact if they wish to enquire about the privacy of their data. They have appointed data privacy officers with clear responsibilities. These are mandated by the law and an auditor can verify it.

What is difficult is to bring about a change in attitude toward customer data as something that belongs to the customer and not to the profit-seeking company. Appearing to obey the law may not be too difficult. Understanding and accepting the intent of the law will take some time and motivation.

This essay was originally posted at my LinkedIn page:

Why is your security product not securing you?

You have spent a few hundred thousand dollars on a flashy security product. Why are you not secure?

You have done your due diligence – you stated your security requirements and made a request for tenders. You invited the three best choices to provide proofs of concept. After the POC, you awarded the tender. Now the product has been set up and the vendors are off your premises. You do not feel more secure than before. Why?

  1. Is the product being used for its key security area?
    Firewalls should be used for managing traffic flowing in and out of your network. Data Loss Prevention tools should be used for preventing data loss. Vulnerability scanners should be used for finding and informing you of vulnerabilities. SIEM and other monitoring tools should be used for monitoring.

    There are plenty of good salesmen who give the impression that their product can do everything. It cannot. Product vendors are happy to talk about how their products “integrate” with other products that are already in the customers’ networks. Understand to what extent they integrate before you take this talk seriously – and how much effort it takes to do the integration. Which brings us to the next point.

  2. Is the product configured properly?
    A firewall that contains no rules is a brick. Everyone who knows anything about firewalls knows that they need to have rules stating what traffic is allowed and denied. More complex security devices also need to be configured before they can be used.

    You may have been told about the product’s out-of-the-box features. Everyone loves out-of-the-box features. The customer has it without having to pay more money to the vendor. The vendor talks it up for an easier sale. Are those out-of-the-box features adequate to give you the security that you need? In most cases, they are merely the starting point, i.e. the place where you start fine-tuning from. In some cases, the out-of-the-box features are so useless that you need to start from scratch.

    Make sure that your product is configured to your environment. This might take many man-days of effort and should be part of your project cost considerations. This is such a crucial point that I may make a follow-up post on it.

  3. Do your engineers know how to use it?
    I do not mean the two-hour “handover” that the vendor engineer provided before he left. Have the engineers spent a couple of days (in some cases a week) going through every item in the device’s interface? Or did they take the vendor’s training course?

    Can they generate a report if needed? Do they know what action to take if a vulnerability scan comes up with list of high-priority vulnerabilities? Can they use your SIEM to find the pattern of events that led to a security attack? Can they use your access control software to find out who last accessed a particular folder? Each security device comes with its particular set of questions. If your engineers do not have the answers, you will not be secure.

  4. Do your administrators have the time to manage it?
    Spare a thought for the administrator. All he wants is to be left in peace. He has now been given an additional device to manage. In some cases, he will play dual-role also as the aforementioned engineer who has to use the product.

    The new device(s) must be added to the administrator’s daily checklist. The administrator must be able to notice whether the device is in a healthy or unhealthy state. If it goes down, the administrator must at least know how to get help from vendor support. I once went on-site two months after a project to find that the device had not been running for a month. #Fail

  5. Is there an incident management procedure in place?
    The product is working. It sends you an alert. Someone is attempting unauthorised access. A procedure needs to be in place for your analysts to take action. This will not happen overnight. At the beginning, you will need to start with a set of the most common use cases that you will encounter with the product. This will need to be refined over the years such that the slightest aberration can be discovered within minutes. You are unlikely to have this in place as soon as the product has been implemented at your site.

These are some of the reasons you might not be secure even after setting up a security product at your site. I might be publishing more details on some of the points raised here.

If you think that I missed some of the reasons your security product is not securing you, I welcome your views in the comments.

This essay was original posted at my LinkedIn page: