May the 4th marks Star Wars Day. Coincidentally, World Password Day, celebrated on the first Thursday in May, falls on May 4th, 2023. What a perfect excuse to bake a Darth Vader cake and write about passwords!
Darth Vader and passwords — is there something in common?
The combination of Star Wars Day and World Password Day is fascinating. Is there something in common with Star Wars and passwords? Well, If you think about Star Wars, something that soon comes to mind is Darth Vader. How does this dark, cloaked figure relate to passwords, then? I think lots.
Let’s compare.
Darth Vader is pretty tall. Passwords should also have enough length to be strong enough.
Speaking about strength, passwords should be strong to prevent guessing and brute-forcing attacks. Darth Vader is apparently strong with the Force.
Darth Vader is a bit scary. Passwords can be frightening, too, if they are leaked. I bet many people in the Star Wars universe hated Darth Vader because of this. I happen to hate passwords.
Darth Vader is behind a mask, so his face is hidden. Passwords should also be kept secret.
Darth Vader has Jedi powers. Passwords wield the power of letting you log in and access confidential information or perform actions.
Darth Vader seemed very evil. However, towards the end, he found some good in himself. Many think passwords are the root of all evil because they are easily phished and may not give the best security. And the amount of passwords you end up having is horrendous. However, often passwords are easy to implement and a good enough way to authenticate users.
Darth Vader cake
Years ago, I saw a cake pan shaped like Darth Vader’s helmet in an online store. Immediately I knew that I must have it. It was so awesome!
A cake pan shaped like Darth Vader’s helmet is definitely a must-have household item!
This time, I tried the recipe that came with the cake pan. After some interpretation of the German text and guesswork of what “1 packet of baking powder” might be, this is the recipe I used:
225 g margarine
160 g sugar
3 eggs
270 g wheat flour
100 g cocoa powder
1,5 dl lactose-free milk
1 tsp vanilla sugar
2 tsp baking powder
Butter the inside of the cake pan and sprinkle fine breadcrumbs on it. At least The Darth Vader pan has many small details that you need to be thorough! Preheat the oven to 180 ºC.
Beat the butter and sugar into a foam. Add the eggs and mix well. Mix the flour, cocoa powder, baking powder, and vanilla sugar. Add about half of the flour mix to the dough. Pour in the milk and add the rest of the flour mix. Mix well.
Pour the dough into the cake pan. Leave room for the cake to rise. If there is any leftover dough, you can make cupcakes in coffee mugs in the microwave (1-1.5 minutes in 800 W will probably do).
Bake the cake for 35-45 minutes. The original recipe said 45 minutes, and I kept mine for 40 minutes. I think 35 minutes would have been enough since the result was a bit dry.
This is how the cake looked after taking it out of the pan, As a result of my very thorough buttering and use of breadcrumbs, some of the breadcrumbs were stuck on the cake.
Let the cake cool for 5-15 minutes before turning it around and removing the pan.
Filling and decoration:
Milk
Raspberry jam
Powdered sugar
Cool the cake thoroughly and cut it into two layers. Moisten the bottom layer with a few spoonfuls of milk. Cover the bottom layer with raspberry jam. Cover the eyes and the mask slits with baking paper. Dust powdered sugar through a sifter on top of the cake. Let the cake moisten in the fridge.
This turned out to be a very pale Darth Vader cake. Maybe he needs some sun?
This time I decorated the cake simply with powdered sugar. Maybe next time, I’ll try black marzipan for a proper Darth Vader look… 😊
What would Easter be without Easter Eggs and the taste of chocolate? Software, on the other hand, does not need Easter Eggs. Probably, there will be a few undocumented features accidentally anyway, without anyone implementing those on purpose. What about cake, then? Do you prefer your cake with or without easter eggs?
I got to admit that Easter Eggs in software can be fun. Doing a Google search for askew and getting a slightly tilted list of search results is surprising and pretty cool. But what about an action game inside Excel? No wonder why the Office package required so much disk space! Bloating software with unnecessary additions does not sound too professional, either. Luckily, I think the only way to buy Excel 95 was on CDs, so you didn’t have to download the thing with painlessly slow modem speeds.
And importantly, if a feature is unknown and undocumented, probably it’s untested. Therefore, you cannot know if an Easter Egg contains bugs or vulnerabilities. When found, these vulnerabilities could have unfortunate consequences.
Are Easter Eggs good or bad? In the case of this cheesecake, I think they were pretty tasty. In software, on the other hand, Easter Eggs are controversial, since unknown features could contain vulnerabilities that we don’t know about.
There are a few very authoritative sources against Easter Eggs in code.
First, Microsoft’s Trustworthy Computing Initiative reasons you should be able to trust what is on your computer, meaning that there is nothing unplanned. Having an undocumented feature does not contribute to that trust. In this blog article, Larry Osterman mentions that Easter Eggs can have security vulnerabilities.
Secondly, the OWASP Application Security Verification Standard (ASVS), the go-to place for web application security requirements, gives a no-go to Easter Eggs. In the ASVS section dedicated to malicious code, ASVS control 10.2.6 requires you to “Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality”.
Easter egg cake
The easter eggs in this cake are not hidden but a part of the decoration on top. The apricot cheesecake recipe is from a Finnish household magazine, and I think the recipe was only published in the printed version. In my opinion, this cake also works with mango instead of apricot.
Cookie crumb crust:
200 g caramelized sugar cookies (Bastogne cookies)
100 g dark chocolate
Filling
6 gelatine leaves
2 dl whipping cream
200 g orange flavor cream cheese
250 g quark
2 cans (á 410/230 g) canned apricot
2 tbsp apricot juice (from the can)
2 dl sugar
2 tsp vanilla sugar
1 tsp ginger powder
0,25 tsp salt
Miniature chocolate eggs and egg-shaped candies for decoration
Line a springform pan (diameter around 20-28 cm) with baking paper. Butter the edges of the pan.
Crush the cookies into fine crumbs with a food processor, or put the cookies into a plastic bag and roll over the cookies with a rolling pin.
Cut the chocolate into small pieces and melt it in a microwave oven or over hot water. Pour the melted chocolate over the cookie crumbs and mix well. Press the crust into the pan.
Soak gelatine leaves in a bowl of cold water for 5 minutes.
Meanwhile, whip the cream and mix it with cream cheese and quark.
Take 2 tbsp of apricot juice from the can and put it into a small pot.
Drain the excess juice and mash the apricots with a blender or a food processor. Mix the apricot mash with the sugar, vanilla sugar, ginger powder, and whipped cream.
Heat the apricot juice in the pot. Squeeze the gelatine leaves as dry as possible and let them dissolve in the hot liquid. Pour the juice into the rest of the filling and make sure to mix it thoroughly.
Spread the filling on top of the crust in the springform pan. Use a spatula to smooth the top.
Refrigerate the cake for at least 6 hours or overnight. Remove the sides of the springform pan carefully. Decorate the cake with miniature chocolate eggs and egg-shaped candies.
Security awareness education sometimes consists of a mandatory boring lecture and an even more boring multiple-answer questionnaire. Having to take the training feels like a punishment. How can we make security training a carrot instead of a stick? Rewarding is one piece of the puzzle. Maybe you can even reward training participants with this lovely carrot cake?
Fear and punishment do not create awareness
The results of poor employee security awareness can be scary. Phished credentials, stolen accounts, compromised devices, leaked data and lost money. But making people afraid of clicking links because they might lose points in a phishing test does not motivate them to learn more about information security. Instead, they will learn to hate security practices. According to Living Security’s blog, anxiety over security may lead to poor decision-making. People might also get so annoyed about the lack of trust the fear-based methods show that they become reckless and don’t take security risks as seriously as they should.
It’s a bad thing if employees are scared about security. Then they might also be too afraid to report security incidents because they fear they will be punished or someone will get angry.
Goals, rewards, and having fun while learning
Would you rather listen to a lecture for one hour or play a game? If the speaker is very charismatic, I might listen to the talk. However, repetition makes the essential security knowledge stick (pun intended). And if you can make the repeating learning activity a game where learners can score points, it works even better.
Different types of content, such as videos, cartoons, and memes make learning about security more appealing, easier to remember, and fun. That’s because not everyone learns by reading and because working life is filled with too many slides and documents you need to read anyway.
While some people are motivated just about learning more, it helps if the learners can feel a connection to the content. How does this help me with my work? How is this related to the things I do daily? And like KnowBe4 reminds us, being able to apply the training also to your personal life, such as being able to advise your children about online security, also makes the security awareness training more relatable.
Ideas for rewards and recognition
So, if rewarding motivates employees to learn more about security, what is a good reward?
According to an article by Hoxhunt, the reward should match your organization’s culture and how you reward other accomplishments.
The reward should also be something that the employees are excited about. SecurityJourney’s blog has a good reminder that some cultures and organizations value certificates, stickers, and t-shirts (as long as they are cool), whereas others don’t care.
Security training rewards can range from certificates to cool stickers, branded t-shirts, coffee shop gift cards and vouchers for movies or the gym.
SecurityJourney also mentions monetary rewards, and similarly, Hoxhunt names vouchers and gift cards. They can absolutely be more appealing than stickers, but there might be an extra hassle with the taxation of the benefits.
According to Living Security, you can also reward the whole team or department: by promising a free lunch or a pizza if the entire team completes the training by a set date you can create some peer pressure and nudge the slackers to take the training.
Last but not least, public recognition works! Lance Spitzer writes in the SANS blog about companies that mention employees who have done the right thing, such as reporting phishing, in their security awareness newsletters. Slack, Teams, and other internal channels also work nicely for this purpose.
A lovely carrot cake
The topic of carrots and sticks inspired me to bake a carrot cake. The full-flavored but not-too-sweet carrot cake is suitable for many occasions – maybe even as a reward for good security practices! 😊 My carrot cake recipe originally had a Halloween theme but left out the festive decoration.
Carrot cake is a classic treat and suitable for several occasions.
Ingredients:
3 eggs
3 dl soft brown sugar (a mixture of sugar and sugar cane syrup)
5 dl wheat flour
2 tsp baking powder
2 tsp cinnamon
2 tsp vanilla sugar
250 g grated carrots
1 small tin of crushed pineapple
0,5 dl crushed hazelnuts
150 g pastry margarine
Line a springform pan (diameter around 24-28 cm) with baking paper. Butter the edges of the pan.
Mix the eggs and sugar into a foam. Mix the flour, baking powder, cinnamon, on and vanilla sugar together.
Pour the excess juice from the tin of crushed pineapples. Tip! You can save the juice and moisten the cake later with it. Melt the pastry margarine. Mix the grated carrots, crushed pineapples, pastry margarine, and hazelnuts.
Mix the dry ingredients and the carrot-pineapple mix into the sugar and egg foam in turns.
Preheat the oven to 175 degrees Celsius. Pour the dough evenly into the springform pan. Bake for 45-50 minutes or until a toothpick comes out clean. Let the cake cool for a couple of minutes, and then remove the edges of the pan. Cool the cake thoroughly.
Filling and icing:
200 g natural flavor cream cheese
200 g vanilla flavor cream cheese
1,5 dl powdered sugar
100 g pastry margarine or butter
Melt the pastry margarine. Mix all ingredients for the icing together.
Cut the cake into two layers. Moisten the bottom layer with a few spoonfuls of juice. Spread a bit less than half of the icing between the cake and the rest on top. You can decorate the cake by sprinkling some crushed hazelnuts on top.
For most people, writing documentation is boring! But what if I told you that writing technical documentation helps reduce security weaknesses? Writing down some notes also makes you a better baker.
What is security debt?
Security debt is the accumulation of insecure design choices and vulnerabilities in software. Security debt can result from missing security updates or not identifying and assessing the threats related to the system. Also, hurrying up to finish the project with the idea of ‘fixing the problems later’ causes security debt.
Examples of such security debt include:
Using end-of-life components
Using components with known vulnerabilities
Storing plain-text passwords and keys in source code
Using default credentials
Not documenting the assumptions taken about security threats and the usage environment.
The first four examples are relatively simple to find with software composition analysis, static code analysis, or source code reviews. But the last one, not documenting the assumptions taken about threats, is the worst kind of security debt. Let me explain.
Poor documentation can result in security debt
Imagine a project where a customer asks you to build something new. You are trying out different things and creating a proof-of-concept. At this point, the customer, let’s call them Customer A, gets excited and thinks you are nearly ready with the new product. Now you are in a hurry to get your product in working condition. Since the product will be installed in an exceptional customer environment, in a factory network not connected to the internet, you decide to cut some corners regarding security to save time because the risks will be small. You finish the project in time, Customer A is happy, and you move on to do other things.
Next year, another customer, Customer B, approaches your company with something a bit similar to the previous project I just described. Everyone thinks it’s possible to modify the solution created for Customer A to cater to that need. The original project team is not available anymore because they are heavily involved with another project. Surely, the other developers are just as capable of doing the modifications: they have experience, and there will be documentation to help them, right?
This time, however, the product is connected to the internet. The previous team had not documented that they had based their design choices on using an isolated network environment. Suddenly, the end-of-life component, weak credentials, and open ports matter much more. Remote code execution, lateral movement, ransomware, boom! Customer B is not happy.
In the worst case, security debt can result in a data breach or ransomware.
What can you do to manage security debt?
You might not get rid of security debt entirely, but you can reduce it to a manageable level. In your team, you can start including these tasks into the backlog or even acceptance criteria of your development items:
Write down design and technology choices, especially when there is a particular reason, such as scalability, performance, or working in a unique or isolated environment.
Perform regular vulnerability scanning on application, operating system, and network levels. Of course, you should patch the vulnerabilities you find.
Search for vulnerable dependencies from open-source libraries and update those components. Tools such as Github Dependabot, Snyk, orOWASP Dependency Track help in this task.
Use secure coding practices, such as implementing proper error handling, input validation, and output encoding.
As you can see, many of the above tasks involve documentation and sharing knowledge. Writing documentation does not mean that you need to write a novel. A few selected lines can be quite enough!
There’s also ‘baking debt’
I admit I have a shortcoming when regarding documenting my baking. I might modify a recipe I have spotted in a magazine or a cookbook or scale the amounts up or down to get suitable portions. However, I don’t bother writing down the correct amount of ingredients, and I need to figure it out every time. Even worse, I might have scribbled down something unintelligible. Luckily, the threats in baking aren’t that horrible: check my earlier post for examples.
There is also the case of spinach and feta cheese pie. Around five years ago, I think I must have baked an exceptionally tasty pie because one of my friends still remembers it. However, I have no recollection of where I got the recipe. Now I wanted to bake this delicacy again. But how?
Spinach and feta cheese pie
After combining a few recipes I tested the following recipe that borrows ideas from Kotiliesi. I think that putting slightly more spinach would not hurt, though.
A piece of spinach and feta cheese pie tastes good both warm and cold.
Crust:
125 g pastry margarine
3 dl wheat flour
3 tbsp water
Beat the pastry margarine and flour. Add the water and keep mixing until the dough becomes solid. Let the dough cool in the refrigerator while you prepare the filling.
Filling:
A small piece of leek
One glove of garlic
150 g frozen spinach
170-200 g feta cheese
2 dl whipping cream
3 eggs
1 dl milk
Salt and pepper
Some cooking oil
Melt the frozen spinach and strain the excess water. Heat a bit of oil in a pan and cook the chopped leak and garlic for a few minutes. Add the spinach and season with salt and pepper. Heat until there’s no excess water left. Let the mixture cool.
Meanwhile, mix the cream, milk, and eggs. Add some salt and pepper to your liking. Cut the feta cheese into small pieces.
Spread the dough into a pie pan. I used a glass pan with a 28 cm diameter. Pour the spinach filling on the dough, sprinkle the feta pieces on top, and finally pour the cream and eggs mixture over the filling.
March 31st marks World Backup Day. What a perfect time to check that there are backups of all your precious data! Remember also to check that you can restore the information if needed.
3-2-1 backup rule
The classic rule for setting up backups is the 3-2-1 rule. It states that you should have:
three copies of data
on two different media
and one of the copies should be off-site.
One copy is the master copy, for example, on your laptop disk or in the storage space of the production environment. At least one backup should be on different media: for example, on an external USB drive, DVD, or in a cloud-based backup system. And finally, one of the backups should be off-site.
Off-site can be at another office, in the cloud, or even in another geographically separated cloud environment depending on where your original data resides.
If disaster recovery is essential for you, you can also check the Unitrends blog. The article introduces the concepts of 3-2-2 and even 3-2-3 backup strategies.
Backups in the kitchen
Backups are needed in baking, too. Maybe you have your best recipes on paper, so they’re always available? And many people keep basic ingredients always in the cupboard in case they can’t go to the grocery store.
I have a sort of backup bread. If I don’t have any bread at home or I want something nice for an evening snack, I often bake tea bread. The original recipe is from my comprehensive school cooking book, but I have modified it a bit.
Backup banana muffins
When I want something sweeter, I whip up muffins from the ingredients at home. If you have some fruit, raisins, nuts, or leftovers of yogurt, you can whip up tasty muffins in half an hour.
I had pretty ripe bananas at home, so I decided to bake banana cocoa muffins. These muffins are simple to make. You will need:
Mix the eggs and sugar into a foam. Pour in the melted margarine. Mix the dry ingredients first together and then into the dough mix with the milk. Cut the banana into small pieces and mix it with the dough.
Preheat the oven to 200 ºC. Pour the dough evenly into a muffin pan. The dough is enough for about 12-16 muffins. Bake for 12-15 minutes or until a toothpick comes out clean. Enjoy the muffins while running backups!
Valentine’s Day is the time of roses, chocolate, phishing, and malware. Yep, the love letters you are getting to your inbox might be a scam!
Valentine’s Day is perfect for social engineering
Valentine’s Day is one of the recurring phishing themes in addition to Black Friday and Christmas. There are two reasons: gift shopping and curiosity.
Chocolate, flowers, and jewelry are typical Valentine’s Day gifts, so cybercriminals are crafting phishing messages that lure people with fake deals. According to Sophos, the phishing site could be imitating a well-known brand.
It’s not only the buyers that should beware. KnowBe4 reminds us of Valentine’s Day delivery scams. You could receive a text or an email stating that you are getting some flowers or a food basket, and you should pay a special delivery fee because alcohol is delivered.
Many find it hard to resist if you get an electronic greeting card from a mystery person. Maybe that coworker is secretly in love with you after all? Most probably, that’s a professional cybercriminal who uses social engineering tricks, such as appealing to emotions and curiosity to get you. Unfortunately, clicking that interesting link could get you malware.
Romance scammers are after your money
What if there is no phishing link in the message? It could be a romance scam!
A scammer could adopt a fake identity and try to establish a relationship on social media or dating sites. The Finnish Victim Support Finland and the FBI both warn that these con artists are excellent at manipulating people, so it’s very easy to believe them.
Romance scammers have various reasons for not meeting in person. They could argue that they live far away, traveling for work takes too much time, or that they have a sick kid to take care of. Soon after the relationship has begun, they start asking for money. As appealing and believable as the story might be, romance scammers are after money.
To balance out the bitterness of all these scams, let’s eat some sweet pie!
Hearty lingonberry and white chocolate pie
For this Valentine’s Day, I decided to take out the heart-shaped pie dish I haven’t used for a while. The combination of slightly sour lingonberry and sweet white chocolate intrigued me, so I mixed and matched a few pie recipes and came up with this treat.
Ingredients for the dough:
1 dl melted butter
1 egg
1 dl sugar
1,5 dl unsweetened yogurt
2,5 dl wheat flour
1 tsp baking powder
1 tsp vanilla sugar
0,3 tsp salt
Filling:
2-2,5 dl lingonberries
2 tbsp sugar
70 g white chocolate
Mix the eggs and sugar into a foam. Pour in the melted butter and yogurt. Mix the dry ingredients first together and then to the dough mix.
Lingonberry and white chocolate pie just before going to oven.
Preheat the oven to 200 ºC. Pour the dough evenly into a pan. Sprinkle the lingonberries and sugar on top. Cut the white chocolate into tiny pieces and sprinkle them on top. Bake for 25-30 minutes or until a toothpick comes out clean. The center of the cake might be a bit moist when you take it out, but it will settle when you let it cool.
The lingonberry and white chocolate pie and was so good that I almost forgot to take a photo. Luckily one piece was still left!
Hack! Data breach! Killware! Halloween is the perfect time to think that is cybersecurity really so scary?
Security talk is often scary
Communication about cybersecurity is often done in a very negative, or even scary, way. It’s a worn-out joke that cybersecurity training in organizations often boils down to prohibiting almost everything. On the national cybersecurity level, the discussions turn to nation-state attackers and Advanced Persistent Threats (APT).
Nowadays there is even a scary-sounding term, ‘killware’, that means malware planted to cause physical harm or even death.
More news about security threats than opportunities
What about news headlines? Let’s take a look at some examples from the last few days.
Security News This Week by Wired on October 30, 2021 highlights four major news items and refers to them with the following headlines:
Only the third headline about Europol arrests can be considered as positive news, although the original Norse Hydro case was very unfortunate. The page has a few smaller mentions, for example, Google Pixel 6 and 6 Pro having advanced security features. But overall the balance is on the negative side of security.
What about security news in The Register? I love its witty wordplay but looks like the recent security news between October 28 and 29 are a bit scary:
Of course, this is a very small sample but I’m pretty sure many who read cybersecurity news or follow the topic on social media have noticed that there’s more talk about the threats than the opportunities. All this scary news results in people being afraid of security-related things.
Let’s highlight the good in cybersecurity!
If something sounds scary or difficult, people will avoid it. That’s why we should communicate about cybersecurity as an opportunity, not a threat. After all, cybersecurity enables us to do many things online — things that required physical access earlier can now be done from the comfort of your home and much faster: shopping, watching movies, banking, taxes. Isn’t that great! So maybe we should have headlines like this:
Patch Tuesday brings security and privacy improvements
Sure way to relax: automatic backups
Advances in cryptography allow controlling power plants online
5 small steps to 100% availability
So let’s highlight the good in cybersecurity from now on, right? Have a happy and cyber-secure Halloween!
Autumn is apple season, so I started yearning for a yummy apple pie. Coincidentally, Apple recently released a patch for an arbitrary code execution vulnerability caused by an integer overflow. What a perfect excuse for baking an apple pie!
A flawed apple
On September 13th, Apple released a fix for an integer overflow vulnerability with an identifier CVE-2021-30860. The flaw lies in how certain macOS, iOS, iPadOS, and watchOS versions handle PDF files. Processing a malicious PDF can lead to executing arbitrary code selected by the attacker. According to Apple, exploitation of this vulnerability has been reported. So better update your Apple devices!
What is arbitrary code execution?
Arbitrary code execution is a type of vulnerability. It allows the attacker to get the same permissions as the vulnerable process has. This way, the attacker can execute commands and code of their choosing on a target system. The worst case is that the attacker gets a root shell.
If you are interested in what type of code the attacker typically runs when exploiting arbitrary code execution vulnerabilities, you can check this article by SearchSecurity.
Arbitrary code execution can be caused by, for example, deserialization vulnerabilities, type confusion vulnerabilities, or – in this recent case – integer overflow vulnerabilities.
What is an integer overflow?
Typically in programming languages, a certain number of bits, for example, 32 bits, is reserved for representing integers. The largest value you can represent with a 32-bit variable is 2^32 -1 = 4,294,967,295 (-1 because of wanting to include zero in the value range). If you like to use both negative and positive values in your program, you will be limited to values between −2,147,483,648 and 2,147,483,647.
Many programming languages and compilers do not give an error when you exceed the maximum value. Instead, they may truncate the value or wrap around, so you get a new figure from the lower end of the value range. This can result in strange behavior or vulnerabilities. Acunetix blog has some good examples of integer overflow cases and consequences.
As a side note, an integer overflow cannot happen in Python, because Python integers have arbitrary precision. A blog post by mortada.net explains the inner workings of Python integers very well.
Apple pie with a vanilla sauce overflow
I found this apple pie recipe in a magazine long ago, but I haven’t tried it before. The instructions are also available online (unfortunately only in Finnish, though). I think the ground almonds on top give a nice touch.
This apple pie is best served with a vanilla sauce overflow.
Ingredients for the dough and filling:
75 g pastry margarine
1 dl sugar
1 dl whipping cream
1 egg
2,5 dl wheat flour
1,5 tsp baking powder
3 medium-sized apples
2 tbsp coarsely ground almonds
Melt the pastry margarine and let it cool for a while. Add the sugar, cream, egg, flour, and baking powder and mix. Spread the dough into a pie pan. I used a glass pan with a 28 cm diameter and. If you use a smaller pan, it should have high edges.
Cut the apples into slices and remove the core. You can also peel the apples if you prefer. Put the apple slices on top of the dough and sprinkle the ground almonds on top. Bake the pie at 200 ºC for 15 minutes.
While the pie is in the oven, mix the following ingredients:
1 egg
1 dl whipping cream
0,5 dl sugar
1 tsp vanilla sugar
Pour the mixture on top of the half-baked pie. Bake the pie on the bottom rack of the oven for another 15-20 minutes or until the filling is firm.
Let the pie cool to allow the filling to set. Serve with a vanilla sauce overflow.
Recently I tried out a new cookie recipe and was unsure how long to keep the cookies in the oven. I had to watch quite closely that I’m not burning them. That reminded me about log monitoring, a crucial part of security that sometimes gets overlooked.
Why do you need to monitor logs?
Too often, I see that applications write logs, but nobody rarely takes a look at them. This kind of behavior is problematic for several reasons:
Performance and availability decrease. You may not notice early signs of faults that may cause you downtime later. Error messages stating that the disk or memory is nearly full and other performance-related things are calls for action.
Data breach attempts go unnoticed. Loads of failed logins? Successful admin logins and weird times or from unusual places? A sudden increase in input validation errors? These could be signs of a data breach, so it’s good to check what’s going on.
Insider attacks go unnoticed. The attack can also come from within, using legitimate privileges. Escalating privileges and creating new user accounts or wiping logs are a few examples mentioned in Graylog’s article that details what information to collect to correlate suspicious activity that might indicate an insider attack.
Your system is faulty. If your server is returning loads of error messages, it could simply indicate that you have broken links on your website or a fault in the system. Errors and hiccups impact your user experience negatively, so you should fix them.
Important systems should have a log monitoring team where someone is always on duty and can react to severe log alerts.
Log monitoring is so vital that Insufficient Logging & Monitoring was added to the list of most typical application vulnerabilities, OWASP Top 10 of 2017. According to OWASP, attackers rely on the likeliness that the lack of monitoring will help them perform their attacks without getting detected.
What should you write into logs?
To be able to detect attacks or faults, you need to log the correct things. So what should you write into logs?
OWASP’s Logging Cheat Sheet provides excellent insight into this topic with its comprehensive list of log sources to monitor and what kind of events to log. Some of the essential things to write into logs include:
Successful and unsuccessful authentication events (logins and logouts)
Authorization failures (a user attempts to access something they don’t have permission for)
Input and output validation failures
Syntax and runtime errors
Starting, stopping, and shutting down services or systems
Filesystem errors
Virus detection
Configuration changes
Use of administrative privileges and the action taken
Changing permissions of users or creating new user accounts
Data imports and exports
File uploads
Granting or withdrawing consent, opt-ins, and opt-outs
Severity or type of the event (error, warning, fatal, info, etc.)
The rule of thumb is to log all high-risk functionality, like accessing personal data, making payments, or administrating a system. For example, due to regulatory reasons, it’s often essential that no user or administrator can later deny that they didn’t do something.
What things must you NOT write into logs?
It might sound tempting to write pretty much everything to logs so it would be later available for review. However, to protect user privacy and system security, you need to omit, mask or scramble certain things.
Again, the OWASP Logging Cheat Sheet is a good reference for checking what should not be written in logs. Items to skip or mask include, for example:
Sensitive personal data
Directly personally identifiable data (such as government-issued IDs, addresses, etc.)
Payment card folder data
Passwords and authentication keys
Session identifiers (you can hash them if you need to track sessions)
Encryption keys
Database connection strings
Other confidential or sensitive data (message contents, trade secrets, etc.)
Information that is illegal to collect or the user has opted out of
The proper log format is the key
After you’ve got the “what happened” part of the log contents right, it’s time to consider the rest of the required information and the formatting. According to the OWASP Logging Cheat Sheet, you should also record when the event happened, where it happened, and who did it to help you understand the situation better.
“When” is, of course, the date and time. What is not so obvious is that all your servers should use NTP to synchronize clocks, be in the same timezone, and log the timezone information (or log in UTC) so it’s evident when the event happened.
“Where” can a line in code, the name of the module, application, service, server or workstation, an IP address, an URL, or any relevant identifier.
“Who” can be a username, device name, IP address, or identification number. Note that you must consider the rules of what not to log.
Logging in all parts of the application should follow the same format, so it’s easier to parse the logs in a log management system, search the events and create alerts.
The art of alerting
The average time to detect a data breach in 2020 was 228 days, as stated in the Cost of a Data Breach Report 2020 by IBM. Such a long detection time means that an occasional glimpse at logs is not enough. In fact, you should be monitoring logs like a cake or cookies in the oven.
To catch security-critical events early, you should create alerts and send them to a monitoring team. According to Sematext’s Complete Guide to Metrics, Monitoring & Alerting, the purpose of log alerts is typically to collect essential information for a human who needs to start investigating the issue. In these cases, you should include the alert severity. Sometimes, you can also trigger automated actions.
Your log management system may have ready-made rules that create alerts. You can also create custom alerts based on your searches, for example.
Alerting rules require maintenance. If your rules are outdated or very strict, they may not catch all security-critical events. On the other hand, if your alert criteria are very lax and you get tons of false alerts, you may get dull with alert fatigue and miss the important events.
Chocolate chip raising cookies to watch over
I was yearning for chocolate chip cookies with raisins, so I combined a chocolate chip cookie recipe and a raisin cookie recipe (both recipes are unfortunately only in Finnish but Google translation looks readable). The baking times for the two recipes were slightly different, so I had to keep an eye on the oven.
I combined two different cookie recipes to get these crunchy but soft chocolate chip raisin cookies. These cookies are easy to make and yummy!
To bake chocolate chip raisin cookies, you’ll need:
150 g pastry margarine
1 dl sugar
1 dl brown sugar
1 egg
3,5 dl wheat flour
1 tsp vanilla sugar
1 tsp baking powder
0,5 dl raisins
80 g chocolate
Beat the butter and sugar into a foam. Add the egg and mix well. Mix the flour, baking powder, and vanilla sugar and add in batches to the dough mix. Cut the chocolate into small pieces, and mix it into the dough together with the raisins.
Preheat the oven to 200 ºC (or 180 ºC if you are using a convection oven). Cover a baking tray with paper. Use two teaspoons to make tiny heaps onto the baking tray. Leave plenty of space in between because the cookies will spread. I used two baking trays and made 21 cookies.
Bake the cookies for 9-11 minutes; the exact time depends on your oven and how large cookies you have. The cookies can remain a bit soft because they will harden a bit as they cool. I kept them in the oven for 11 minutes and kept a close watch so that the cookies wouldn’t start getting too dark on the edges.
Maybe checking those log alerts is much more fun when you have a plate of these crunchy chocolate chip and raisin cookies on your desk?
When the strawberry season is at its best, it’s my summer tradition to make a cake with layers of fresh strawberries and fluffy cream. Yummy! These delicious layers inspired me to write about baking security into the TCP/IP Internet protocol suite.
It’s good to have security controls in many layers
As security controls might sometimes fail due to mistakes or vulnerabilities, it’s good to have multiple layers of security. This principle applies to all kinds of security practices ranging from application security, network security, and physical security. Let’s go through the TCP/IP Internet protocol suite layers from top to bottom and see what security measures we can use on each layer. Note that many protocols used on the internet probably haven’t been designed with layering in mind, so these may not apply in all cases.
The application layer is like the icing on a cake
The application layer is like the icing on a cake – the first one you encounter. Examples of application layer protocols include HTTP, DNS, SMTP, and SSH. Protection mechanisms in the application layer include (but are not limited to):
Input validation. Check what data you get in form or URL parameters, API requests, protocol parameters, files, and other input and validate that it contains known good content. If it doesn’t — reject it. Input validation typically falls as the responsibility of the application or API on top of the protocol, but it’s such an important topic, so I thought I’ll mention it here.
Output encoding. Always encode the output in the expected or agreed format so that other applications can present it correctly. Again, this is typically something for the application or API to handle.
Fuzzing. If your system requires strong reliability or you are using a not-so-mainstream protocol implementation, fuzzing is for you. With fuzz testing, you can check how well the implementation handles malformed messages.
Application layer firewalls. As an additional security control, application layer firewalls, such as Web Application Firewalls (WAF), can protect your apps from injection attempts or other application-layer attacks. WAFs are especially useful in case you cannot, for some reason, immediately patch a known application-layer vulnerability.
Security updates. Related to the tip above, if a protocol implementation, server software, or application has a security update, install it.
Session management. In the Internet protocol suite, session management also belongs to the application layer.
DNSSEC. The Domain Name System Security Extensions (DNSSEC) protects from spoofed DNS data with the help of digital signatures.
Layered security is not a piece of cake: there are many threats to consider in each protocol layer.
The transport layer is the messenger
The task of the transport layers is to establish a host-to-host channel for sending data. TCP and UDP are the most known transport layer protocols. To protect the transport layer, you can use the following security measures:
Server hardening. Make sure that only the required services are on and listening to network ports.
Firewalls. Allow inbound connections to be established only to the required TCP or UDP ports. Restrict outbound traffic to responses to existing connections and other required domains, such as for fetching updates.
DDoS protection. An intrusion prevention system (IPS), some firewalls, or DDoS protection services by hosting providers or cloud service providers can protect you from a transport layer distributed denial of service attack, such as SYN flood.
Fuzzing. In the case of exotic protocol stack implementations or special reliability needs, fuzzing can help you check that the protocol implementation does not contain vulnerabilities.
The internet layer carries data from one network to another
The internet layer is the layer with IP addresses that differentiate different networks from each other. Internet layer protocols (for example, IP, ICMP, IGMP, and IPsec) provide a transport mechanism from one network to another by sending the data to a suitable next hop. The next-hop router then forwards the packet to another network, if needed. The next-hop networks are defined by routing protocols.
Interestingly, the most essential routing protocol on the internet, BGP, is actually an application layer protocol. Another typical routing protocol, OSPF, belongs to the link layer.
To following security measures help you build security on the internet layer:
Hardening routers, VPN gateways, and other network devices. It’s crucial to ensure that attackers cannot access network devices to change their configuration, manipulate routing or monitor traffic.
Firewalls. Allow connections only to and from required networks. Perform ingress filtering to drop packets from outside the network with a source IP address inside the network and egress filtering for the opposite.
DDoS protection. Internet layer distributed denial of service attempts to overwhelm or crash the network devices or use up all the bandwidth by sending IP, ICMP, or IPsec traffic your way. There are many DDoS mitigation services to help you.
Fuzzing, as explained with the previous layers, can be considered on the internet layer, too.
The link layer establishes connections between devices
The link layer is the lowest layer of the TCP/IP model. Protocols in this layer include IEEE 802.3 (Ethernet), IEEE 802.11 (WLAN), ARP, L2TP, and many others. There are several security measures you can take on the link layer:
Physical security. Limiting access to network sockets and cabling prevents unauthorized persons from connecting to the network. Of course, this is not always possible.
Authentication. Requiring authentication to connect to the networks, for example, in the form of a WLAN password, prevents others from accessing your network.
802.1X network access controls. Identifying devices and users with passwords, or even better, certificates, prevents rogue devices from plugging into your network.
Static ARP to IP address mapping. Managing the mapping may require quite a lot of management, so it’s not for everyone.
The security measures depend on the link layer protocols you use, the number of devices, and of course, the data that you want to protect.
Alternative representation: the OSI model
Another way of describing and categorizing network protocols is the OSI model with its seven layers. There are two noteworthy things in the OSI model. Firstly, the data link and physical layer are separated, which makes sense. Secondly, there’s a separate presentation layer below the application layer. The presentation layer includes encoding standards such as MIME, ASCII, and ASN.1. A crucial presentation layer security measure is that you should always check the correct MIME type of files. And as always, input validation and output encoding are essential to ensure you get meaningful data that you can show correctly.
TCP/IP layered strawberry cake
This time I baked a simple and small cake with just two eggs: it’s perfect for a small party. When you count in the filling and the decorations, this strawberry and cream cake also happens to have four layers: exactly the number of protocol layers in the TCP/IP protocol suite!
You can ponder the security controls of the TCP/IP protocol layers while munching through the tasty layers of this strawberry and cream cake.
Ingredients:
2 eggs
0,75 dl sugar
0,5 dl wheat flour
0,5 dl potato flour
0,5 tsp baking powder
For the filling and decoration:
4 dl whipping cream
0,5 dl milk or juice
0,5-1 dl strawberry jam
1,5 dl strawberries
Line a springform pan with baking paper and preheat the oven to 175 ºC. I used a springform pan with a diameter of 20 cm, but with a smaller pan, you’ll get a higher cake (and possibly extra layers).
Mix the eggs and sugar into a foam. Mix the flours and the baking powder first together and then to the dough mix.
Pour the dough evenly into the springform pan. Bake for 20 minutes or until a toothpick comes out clean. Let the cake cool for a couple of minutes, and then remove the edges of the pan. Cool the cake thoroughly and cut it into two layers.
Whip the cream until stiff peaks form into the foam. You can add some vanilla sugar and regular sugar to sweeten the cream. Cut about half of the strawberries into slices. Moisten each layer with a few spoonfuls of juice or milk. Cover the first layer with strawberry jam, strawberry slices, and a bit less than half the whipped cream. Cover the top and the edges of the cake with the rest of the cream. Put whole strawberries on top. Simple but tasty!
Several things can go wrong with baking: meringue flattens when you take it out of the oven, cookies are burnt, the cake is raw on the inside, kitchen catches fire. These threats are something you can prepare for so you can reduce the likelihood or limit the damage. Similarly, in cybersecurity, you can identify problems early and plan mitigations. This is called threat modeling or threat analysis. I’ll introduce the idea and concepts of threat modeling through baking analogies.
Threat modeling identifies potential problems early
The purpose of threat modeling is to think, what can go wrong and what we can do about it. Usually, when people talk about threat modeling, the threats are related to harming security and privacy in an IT system or an application. System unavailability, information leakage to unauthorized people, lack of logs, or getting root access are examples of threats.
In general, a threat can be any scenario with negative consequences in the context of the system that you are threat modeling. Let’s think about the threats in baking. Examples of things that can go wrong are:
The cake is sticking to the pan and does not come out.
The pastry is raw from the inside.
The pastry is burnt.
Cookies grow into one giant cookie.
Meringue flattens when taken out of the oven.
Yeast does not activate.
You forgot to add an important ingredient to the dough.
You measure an incorrect amount of some important ingredient.
You don’t have all the needed ingredients in your cupboard and you have started already.
Dough or cake accidentally ends up on the floor.
The bottom of a springform pan falls off and all the dough flows over.
Your kitchen catches fire.
I think pretty much all of these have happened to me, except luckily my kitchen catching fire. Some of these shortcomings apply to only certain types of pastries or baking. That’s the way the cookie crumbles! Similarly, there are several threat modeling techniques and they fit different purposes. I’m going to explain these next.
Plenty of threat modeling methods
There are plenty of threat modeling methods. It’s often a good idea to use a few methods to get more viewpoints on the different threats the system might face.
STRIDE identifies threats from the architecture
STRIDE is a method oriented to data flows and works well on understanding threats related to architecture. Each letter in STRIDE comes from a specific type of threat:
S – Spoofing:
T – Tampering:
R – Repudiation:
I – Information disclosure:
D – Denial of service:
E – Elevation of privilege:
If iterating threat types with a data flow diagram sounds dull, you can play a card game called Elevation of Privilege, by Microsoft. The threat examples in the cards help you identify security problems (and beat your colleagues).
LINDDUN identifies privacy threats
The privacy threat modeling methodLINDDUN is also meant to be used with data flow diagrams but I think it also serves well as a thinking aid. Similar to STRIDE, LINDDUN is a mnemonic:
L – Linkability:
I – Identifiability:
N – Non-repudiation:
D – Discoverability:
D – Disclosure of information.
U – Unawareness:
N – Non-compliance:
There’s also a card game, called LINDDUN GO, so again you can play while searching for privacy threats.
Evil user stories: what bad should not happen?
Evil user stories, also referred to as misuse stories or abuse cases, are a way of discovering threats from a more functional point of view. There are few ways to creating evil user stories. The first one is using the following format:
“As a hacker, I want to steal credit card numbers and sell them in darkness” or
“As a bored teenager, I want to launch a denial of service attack on a popular website so I can brag to my friends”.
The challenge with this approach is that you might run out of ideas of what a hacker or disgruntled user might want to do. Another way is to first list, what important assets you have (your source code, personal data of customers, credentials, etc.) and then think, what bad should not happen to these important data or resources. You can do this by completing the sentence, “An attacker should not be able to do…”. For example:
“An attacker should not be able to steal credit card numbers” or
“A user should not be able to see someone else’s private profile information”.
So many ways to think about problems
Then there is the PASTA model (which comes from Process for Attack Simulation and Threat Analysis) and OCTAVE methodology (Operationally Critical Threat, Asset, and Vulnerability Evaluation), or you can use threat personas. Drawing attack trees, that visualize how threats happen and what are the consequences, is a method in its own, too. There are also threat modeling tools, where you draw the system architecture complete with data stores, servers, and connections. The tool provides you a list of all kinds of weaknesses related to these components.
Whichever threat modeling techniques you use, it’s important to be systematic, take multiple viewpoints, document your results, and use findings to improve the security and privacy of the system you are threat modeling. Also remember, that threat modeling is not a one-time thing: it’s something you should repeat continuously, for example, with each new change you are introducing or in every sprint. You can read more about good threat modeling principles from the Threat Modeling Manifesto.
What can we do about the threats?
An essential thing in threat modeling is thinking that what can we do about the threats. Can we avoid the threat scenario? Can we make it less likely? Can we reduce the impact?
Similarly to avoiding a total baking failure by using clean utensils and exact measurements, you can redesign your application in a slightly different way or add some more security features to protect you from the threat scenarios you have identified. Sometimes you cannot avoid the threat fully (internal threats, typically) but you can build for example logging and monitoring to be able to identify an incident as early as possible.
Impact in baking is maybe not so bad
In many cases, the consequences of baking threat scenarios are maybe not too bad, after all, especially if you’re only baking for your family and friends. The cookies might be slightly irregular, the buns are a bit uneven or the cake is lopsided. So what? Unless you burn the pastries into coal, your homemade delicacies are probably going to taste good even if they look funny. It’s another matter of course if you’re supposed to be a professional baker or you’re baking for an important event on the next day.
Baking is not always a piece of cake! Nor is application security, Luckily, you can prepare for security problems with threat modeling.
Understanding the impact and likelihood of a threat scenario is important for being able to prioritize the mitigation options. Your kitchen catching fire is maybe a very unlikely event if you’re careful enough, but the consequences are critical, so it’s wise to have a fire blanket nearby.
On the other hand, cake sticking to the pan or overgrown cookies are more probably scenarios but that’s usually quite harmless. With security and privacy threats, you’ll want to weigh out the risk more seriously.
Baking and threat modeling well together for another reason, too: everybody wants to join your next threat modeling session if you promise to bring homemade cookies!
I love browsing cake recipes. All those yummy curds, zabagliones, and mousses and artfully arranged decorations over the top. Especially chocolate cakes seem to sometimes be so filled, stuffed and topped with all sorts of chocolate that they go overboard. In fact, cybersecurity can also go a bit overboard sometimes. I’ll share my experiences of getting too enthusiastic and over the top with security along with a very, very chocolatey cake recipe.
Too hard? When hardening gets out of hand
The purpose of security hardening is to eliminate all the weak spots of a system by minimizing the attack surface: disabling unused features and services, disallowing access to unused ports with a firewall, changing default accounts and other default configurations to more secure ones. Hardening is something you should do for every production system. Naturally, I try to harden internet-connected things at home as much I can.
A while ago, I switched to another internet service provider and the new provider sent me a new home router. It was preconfigured to work out of the box. All devices come with a unique WLAN SSID and password as well as an admin password printed on a small card at the back of the device so there’s no immediate need to reconfigure the router. However, I knew that there are loads of unneeded settings enabled by default so off I went to browse around the admin panel. I changed the admin password to a longer and stronger one, disabled UPnP and IPv6, configured guest WLANs, and all that. When I came to remote management settings, I just continued clicking away without thinking, disabled all options, and pressed Apply. Oops.
The device allowed me, unfortunately, to disable remote management from all interfaces, even the one I was using right now, so I shut myself out. Internet access was working fine but in case there would ever be trouble or I wanted to change the configuration, I wouldn’t be able to access the admin interface. Sighing, I long-pressed the small reset button at the bottom of the home router and started going through the settings again.
Untypable passwords
Back in the days when I was studying at the university, it was uncommon for people to bring laptops to lectures. Most people wrote their notes on paper and I preferred that too. One of the reasons was that there weren’t enough power outlets in the lecture halls and the battery lives were not so great. So mostly I kept my laptop at home but sometimes I brought it along to the campus and other not-so-secure locations. When I heard in an information security course I was taking that it is good practice to set a BIOS password, naturally, I did set one. It was a very good one, too, with special characters, small and large letters and it was of considerable length. However, it didn’t occur to me that while I was able to use a Finnish keyboard map while setting the password, the only available keyboard layout during boot was US English. No matter how hard I tried, I was not able to produce the same special characters. I had just locked myself away from my one and only laptop.
I was really worried. All my exercise reports and other important documents were on the laptop! Luckily, the company where I had bought the laptop from, was still open so I packed my laptop, took the bus, went to the shop and explained the situation. They had never heard of such an issue and were completely out of ideas on how to help me. Frustrated and even more worried, I went back home. Meanwhile, my friend to whom I had explained this annoying situation, had done some googling. He had found out that with my laptop model the BIOS password could be reset by removing a small battery attached to the motherboard. It sounded like a very poor design choice but it was also a design choice that could save me. So I took a screwdriver (luckily, the laptop had regular cross-heads crews), opened the bottom, and located the battery. I removed the battery, waited for five long minutes, put the battery back, and booted my laptop. No BIOS password prompt, just the familiar LILO boot loader screen. Phew!
Unfortunately, I didn’t learn the lesson fully then. Frankly, I think I thought that these kinds of issues would have been fixed in the years that had passed. But again, when setting a Bitlocker password for a brand new computer, the keyboard layout during the setup phase and the boot phase was different. It was a fresh install so I lost do data, just my time when I reinstalled the operating system. But now I’ll remember forever that passwords that need to be typed very early during boot should consist of characters that are easy to type regardless of the keyboard layout.
Going to pieces
Banks, insurance companies, and all kinds of companies tend to mail documents that contain personal information that I don’t want to throw into the trash to protect my privacy. That’s why I’ve bought a small and inexpensive shredder for home use. I think the shredder makes decently small pieces of paper but I guess its cheap price shows in the fact that I’ve been able to overheat it a few times by shredding too much paper at one go. I had to let it cool down for several hours to be able to shred again!
Chocolate cake that goes overboard
Locking myself out of accounts because refusing to trust any device, blocking JavaScript making my internet browsing a misery, keeping my passwords in a bit too secure place… oh boy, I think I’ve sometimes gone a bit overboard with security. To match these fun memories I baked a cake that also goes overboard with chocolate and caramel flavors.
Chocolate cake with caramel filling and confectionary on top. Yummy!
The recipe is from a book called Suklaaunelmat (translates to Chocolate dreams) published by Gummerus but I switched the wheat flour to gluten-free flour and changed the filling and decoration a bit.
Here are the ingredients:
200 g butter or pastry margarine
1,75 dl sugar
4 eggs
4 dl flour (I used all-purpose gluten-free flour mix)
2 tsp baking powder
1 tbsp cocoa powder
50 g melted dark chocolate
For the filling and topping:
5 dl whippable caramel cream (I used Valio kinuskikerma but I’m sure it can be replaced by mixing caramel sauce and whipped cream)
0,5-1 dl orange juice, apple juice, or milk
For decoration:
Different kinds of confectionary
50 g dark chocolate
Line a springform pan with baking paper and preheat the oven to 180 degrees Celsius.
Mix butter and sugar into a foam. Add eggs one by one and mix well after each egg. Add the flour, baking powder, and cocoa powder in batches to the dough mix. Scoop the melted chocolate and mix at a slow pace.
Pour the dough evenly into the springform pan. Bake for 40 minutes or until the cake springs back a bit when you press it. Let the cake cool for a couple of minutes and then remove the edges of the pan. Cool the cake thoroughly and cut it into three layers.
Whip the caramel cream until stiff peaks form into the foam. Moisten each layer with a few spoonfuls of juice or milk (a bit of rum might fit nicely, too) and cover the layer with the whipped cream. Use about half of the cream for the layers and leave the rest for the top and the edges.
Grate the chocolate and spread it over the top and edges of the cake. Cover the top with the confectionary or make a pattern. Enjoy! Has your security gone overboard, too?
Bake Security In 