toheccwithsec

[toheccwithsec]

Employer Security Principles

In seeking to analyse the practical applications of security, I undertook a short online training course through my employer about their security principles. I thought they were quite well-framed and pithy, so I’ll share a bit about each of the company’s 7 security principles below: - Privacy By Design: The guiding idea here is that we should incorporate privacy from the get-go and throughout the lifecycle of the product. This is to best ensure that all stakeholders have clear and consistent privacy policy, and eliminate privacy loopholes in the system as best we can. - Data Minimisation: When gathering data from users, only collect what is necessary. This reduces the impact of any potential data breach/leak and allays privacy concerns. - Retention and Disposal: Get rid of data when it is no longer necessary. Data that is necessary now may not be required in the future, and similar to the previous point, this minimises the impact of any potential data breach/leak. - Notice and Transparency: When collecting personal data, let users know what it is and why it’s being collected. This ensures that users are informed about the data that the company takes, and can make a choice as to the collection of that data. - Consent: Make sure that the company has the necessary and proper consents before collecting or processing personal data. A lack of clear consent could lead to information being collected that a customer wishes to keep private. - Accuracy: Ensure that personal data is accurate and updated. Incorrect or out-of-date personal information could cause legitimate users to run into login and support issues, and simultaneously, could make it easier for hackers to exploit accounts e.g. using outdated phone numbers. - Access: Only access data that you have a legitimate business purpose to access. As an employee, there is a lot of information that you technically have the ability to access, but it’s critical to create a culture of only knowing what you need to know, so as to minimise the threat of social engineering and insider attacks.

[toheccwithsec]

Tutorial Exercise: Alien Report

This was a rather vague and peculiar challenge, whereby we were tasked with the following conundrum: Suppose you are the friendly Major M from the base who can see the alien A but who cannot see the invisible man X.

Q: What would you M do to get from X his report on the Alien's (A's) planet? One critical assumption we probed was whether M and X have had any pre-existing contact/relationship. The assumption we made for this exercise was that they do, as otherwise, there is no potential for shared secrets and the challenge is pretty much rendered moot.

Another detail of interest was the potential ability of M to perceive X through other means (e.g. can M hear, touch, smell or taste X?) We went on hard mode and said no. This includes the ability for X to physically manipulate surrounding items e.g. X cannot push a box to indicate something. Ultimately, after debating the merits of ciphers and schemes to ensure both integrity and authentication, we were left stumped.

The biggest stumbling blocks were the following:

- The Alien could torture X into always revealing the correct answer - The Alien could perhaps read the mind of the invisible man and get any shared secrets that M and X have - The Alien could even control the mind of the invisible man - Diffie-Helman is subject to man-in-the-middle attacks

[toheccwithsec]

FINAL INFOGRAPHIC! Inspired by the fascinating social engineering presentation given in lectures, for my final poster, I wanted to bring literacy of social engineering techniques to a wider audience.

In particular, social engineering is a critical topic for the general public to understand, as it is something that can directly involve people in almost any setting regardless of degree of technical literacy or degree of seniority, and even knowledgeable, intelligent people are still vulnerable. It could be a doctor, a receptionist, a cashier, a security guard, a software engineer, whoever.

Key to this was first defining social engineering, then highlighting the 5 key ‘vectors’ of social engineering as well as the lifecycle of a social engineering attack. Ultimately, if people understand the anatomy of an attack and the key tactics that can be used, the hope is that this content will instil a greater awareness of interactions with people we do not know well.

[toheccwithsec]

As per the recent publication from USYD and Data61, over 2000 fake apps were discovered in the Google Play Store recently, including duplicates of popular games like Temple Run. These can present quite a threat to unsuspecting users through spreading malware and stealing data through excessive user permissions. In coming across this story in the news, I wondered how the average user would be able to spot the difference. After doing some further research, I identified 5 key traits to look for in a suspicious app: - App icon has slight differences in colour/shape/size of elements - Reviews are often low and/or polarising, with 5-star reviews often using the same text or unusual syntax and 1-star reviews warning other users about the app’s dangers. - # of downloads is unusually low for an app one expects to be popular - The app and developer name have additional words or characters that shouldn’t be there, or uses words that look similar. - The description contains spelling and grammar errors, or other unusual language and links. Users should consistently remove unused apps, and if they think an app that they have is fake, they should firstly clear the app cache and app data. Following this, they should delete the app; if the app has gained access to admin permissions, the user should reboot the device in safe mode to delete it. Failing this, the user should perform a factory reset. For any apps users spot that appear to be fake, make sure to report the app to the App Store/Play Store so that other users don’t fall for it!

Ultimately, with this infographic, I hope to provide a general audience with foundational literacy in what fake apps are, how to tell whether an app is fake, and best practices for keeping fake apps off one’s device.

[toheccwithsec]

The word “cookies” came up in one lecture’s extended security presentation and I took a moment to appreciate that I didn’t really know how cookies worked. I knew vaguely that cookies were things used by a website to store information related to you, but not much beyond that. Diving deeper for this infographic, I wanted to give an easy-to-understand explanation of how cookies work (user has an http request that the browser sends to the server, the server returns the request with cookies, the user installs the cookies and these are remembered across other pages/visits to the website). Beyond this, I felt it was important to convey to a general audience that not all cookies function in the same way. Some are 1st-party cookies enabled by the website to allow for an improved user experience (imagine having to log in on every page!). Others are 3rd-party cookies used for advertisement tracking and plugins to share content through social media. Another key distinction was the session vs persistent dynamic, making the point that whilst some cookies only last while your browser is open, others stick around a lot longer. Given not all cookies are created equal, the actionable takeaway is for users to clear their cookies regularly (gets rid of unnecessarily persistent cookies) and to read terms before accepting cookies (some 3rd-party cookies may take A LOT of data).

[toheccwithsec]

Inspired by James Veitch’s comedy series on replying to spam emails, I chose phishing as a standalone topic from social engineering given its sheer economic impact. 90% of data breaches are caused by phishing, and Australians alone lost $489 million from phishing scams in 2018. In particular, phishing is such an important area to improve security literacy because attacks are often geared towards those with a lack of technical know-how. 6 key things to check for with an unexpected/unusual email: - Bad spelling and grammar: Your friends making typos is one thing, but if an email is supposedly official business communication (often mimicking a company template), one major red flag is when there’s clear spelling and grammar mistakes. PayPal’s legal and marketing team have probably scrutinised the copy of their emails relentlessly. Some random dude in a non-English-speaking country trying to make a quick buck? Perhaps not. - Unrecognised sender address: If their email domain looks somewhat similar to a familiar company but does not follow the same format e.g. security@amazon-shopping.co, be very wary. This is a classic case of spammers trying to imitate a legitimate company. - Sense of urgency/necessity: Fraudsters will often create a false sense of urgency, whether through time-bound conditions, threats or instilling fear. This is because sending users into a state of panic leads to rash decision making and reduces careful perusal of the email’s red flags. Examples include supposed data breaches, accounts being locked, and mandatory password changes. - Generic greeting: A business with which you have an account/existing relationship is a lot less likely to use Dear Customer or Dear Member as the opening to the email. Not a dealbreaker, but certainly a warning sign. - Unsolicited attachments: Often, phishing emails will ask you to download a file like a .zip file to review account details or update your password. This is a dead giveaway; legitimate businesses would not request sensitive information in this manner. Even without such requests, unexpected attachments may well contain malware. - Unusual address when hovering links: Be sure that any hyperlinks in the email actually link to the address typed. A safe way to check this is to hover over the link with the mouse and see the URL that pops up. With phishing emails, this will often be a very different URL. Do not click through!

[toheccwithsec]

Deferring software updates is almost becoming a tradition of our generation, with countless memes having been made about the refusal of software update requests. Updates are oft the butt of the joke, but we gotta put some RESPECC on their name. With this infographic, I hope to provide a simple explanation of why it’s a bad idea to delay updates (something I admittedly often have done myself). Ultimately, if you don’t update your software regularly, you may well be exposed to known security vulnerabilities that can be exploited by hackers. The developers creating a patch is useless if you don’t install it! For the users of programs like VLC, Skype and Mozilla, evidently many are currently running this risk. Trading a minute of time for peace of mind seems like a fair deal. Better yet, an actionable takeaway is just to turn on auto-update so you don’t have to consistently check to see whether things are up to date.

[toheccwithsec]

Inspired by a security briefing at work and the Google secret lab exercise from tutorials, my next infographic focuses on the continued importance of physical security even as we enter an era of increased focus on cybersecurity. The underlying thesis is that the two are nowadays interdependent. A great cybersecurity protocol is rendered useless if a hacker can penetrate the underlying physical resources of the system. Likewise, robust physical security systems increasing involve technological measures from biometric scanners to video surveillance. The four tips I gave cater to a corporate audience, based on observation of best practices that are commonly broken yet require no advanced resources to do well.

[toheccwithsec]

Inspired by the passwords presentation in class and having personally had issues with breached and forgotten passwords, my next poster focuses on 6 actionable tips for a general audience to improve their security practice concerning passwords.  The six tips I thought would be both simple and useful:

- Have greater password length: Special characters and numbers aren’t that useful if your password is only a few characters long. Longer passwords (assuming they’re not blatantly obvious public information like your name) are much trickier to brute-force. - Use two-factor authentication: Easy way to derisk password attacks. Even if somehow, your password is discovered, requiring verification via a text to your phone creates a significant barrier for any hacker trying to access your account. - Don’t store passwords or their hints in plaintext: Over-the-shoulder attacks and application breaches make this one a no-go. Always encrypt! - Don’t use personal information to make your passwords if it is public knowledge: There’s a lot of content on Facebook, LinkedIn, Instagram, etc. that you may have not posted yourself but may still involve you. Err on the side of caution when choosing what personal information (if any) to use. - Use a password manager: Having now asked a sample size of ~20 people about password manager use (many of whom were computer science students), only a few actively used password managers. Using them allows for a system whereby every service you use can have a different, complex password without the need for you to remember it. - Do a check to see if your existing passwords have been compromised in past breaches: Upon checking, two of my passwords have in fact been breached before, and I was still using these and their variants across several websites. NOT GOOD!

[toheccwithsec]

First poster fully finished! This idea came from one of my first blog posts, where I saw that Google Chrome listed ‘Not Secure’ next to HTTP sites and realised I myself didn’t understand way. The main aim of the poster is to explain in simple terms what these protocols are, how they differ, and an actionable step going forward for a general audience.

[toheccwithsec]

> DO NOT KEEP OPEN

Wedged open on the weekend when the building requires swipe access.

Security in practice eats security policy for breakfast.

[toheccwithsec]

Thanks for the cheat sheet my guy!

Bits of a Penguin

Let’s make this post actually useful and note that:

2^10 = 1,024 so we say 1,000 is roughly 10 bits of work

2^20 = 1,048,576 so we say 1,000,000 is roughly 20 bits of work

2^30 = 1,073,741,824 so we say 1,000,000,000 is roughly 30 bits of work

While we’re at it, the new times tables:

0 bits = 1; no bits of work, it is known 😂

1 bits = 2;

2 bits = 4;

3 bits = 8

4 bits = 16

5 bits = 32

6 bits = 64

7 bits = 128

8 bits = 256

9 bits = 512

10 bits = 1024

Alright below is some haphazard maths for the bits of penguin activity:

Keep reading

[toheccwithsec]

Something Awesome Update: WK6

My ‘Wait a Sec’ infographics are under construction! Check ‘em out here: https://www.canva.com/design/DADdMWDm0no/DOlYaenYp9t1cLboVieKoQ/view?utm_content=DADdMWDm0no&utm_campaign=designshare&utm_medium=link&utm_source=sharebutton Final list of infographic topics, with a focus on less technical audiences: - HTTP vs HTTPS - Cookies: More Than a Biscuit - P*ssw*rds: 8 Tips To Not Get F*cked - Gone Phishing - Fake Apps - Let’s Get Physical: Physical Security  - Social Engineering - Updates: An Unrequited Love Story

[toheccwithsec]

>when you require the user to include special characters in their password but display it to them in plain text

Security Everywhere: Kensington McDonalds

Last week, I was up late doing my stats assignment and got hungry, so I went to the McDonalds near Uni. After ordering my food I was waiting near the pick up area and saw this.

Here is a door to get into the staff area has a lock and when I subtly pushed against it, it was locked. 

I started thinking of ways on how I would get in and an immediate vulnerability presented itself. (Try think of one)

Keep reading

[toheccwithsec]

According to my sources, both the fellows mentioned in the dessert spoon debate had the incorrect answer.

[toheccwithsec]

Should we allow driverless cars on the roads?

Assets of Concern

Reputation: How will the presence of autonomous vehicles on our roads shift perception of our cities by tourists and foreign investors, and perception of government by its people should something go wrong?

Road Infrastructure: How will road infrastructure need to change to handle these vehicles. Will we need to remake or alter road signage to suit these vehicles?

People: How will their introduction affect employment opportunities for people who currently rely on driving skills for their profession? How will we protect people from accidents with autonomous cars? How will we qualify people to operate these vehicles?

Law: How will the legal system adapt to define the responsiblity of drivers and passengers in autonomous vehicles, as well as the responsibility of manufacturers in accidents? Will road and parking laws need to change?

Charging/Fuelling Infrastructure: What systems need to be put in place to ensure such vehicles can be serviced?

Money: How much is it going to cost to build the necessary infrastructure and support to allow these vehicles to operate viably?

Data

Risks

- Potential for cars to be hacked - The computer malfunctions in such cars / the algorithm has flaws - Job loss for those who drive for a living / work in the automotive industry and ancillary industries - Car manufacturers given excessive power in deciding priority of lives (biased algorithms)

Mitigation Strategies for Risks

- Develop set of minimum encryption standards for autonomous vehicles - Conducting further testing of these vehicles, mandate manual override functionality - Focus on training and education programs for unemployed people to gain skills relevant to the maintenance, servicing and repair of autonomous vehicles - Develop regulatory committee to work alongside tech and car companies in creating a system of autonomous vehicle standards

Recommendation

We should NOT change the legislation to allow driverless cars to be on the road until:

- Several, independent trials have been conducted with significant sample size showing the rate of errors for autonomous vehicles is smaller than or equal to the rate of error for human drivers - Road and charging/fuelling infrastructure changes have been assessed - Legal responsibility for drivers and manufacturers has been clearly defined

[toheccwithsec]

Houdini Challenge Reflection

In designing an appropriate protocol for the Houdini challenge, my team and I placed priority on the CIA principle of ‘Authentication’: an act, process, or method of showing something to be real, true, or genuine. We leveraged several layers of security for our system of authenticating the message from the grave.  - Providing the answers to several shared secrets to Bess in a specified order e.g. “Where was the first place we met?” then “What was our favourite park to walk in?” then “What was the last birthday gift I gave you?” etc. - Going into the nearest wardrobe for 10 seconds  - Coming out with one purple shoe and one blue shoe

Whilst it’s a very elaborate setup, upon reflection, the weakness in this idea was that if someone hypothetically solves the protocol, the solution does not change.