I’ve recently decided to brush up on my programming skills with one of the courses on Udemy. Despite completing a degree in Computer Science back in the day, my recent focus has been away from software development and a lot has changed since I graduated.
At university I studied mathematics and algorithms but actual programming was performed on archaic languages – such as Pascal for high-level and Assembly for low-level programming.
Although they provide a solid foundation, I was looking for something more practical and because of this I ended up taking up Python because of its versatility. Python is not only widely used, but can also be applied to a variety of projects, including data analysis and machine learning.
The course has been very good and Jupyter notebooks with extensive comments and exercises are available for free on GitHub.
You can start applying it in practice straight away or just have some fun with your own pet projects.
If you’re an experienced developer or just want to have some extra practice, I found the below brain teasers quite entertaining:
- Basic coding practice – CodingBat
- Project Euler
- More coding practice – CodeAbbey
- DailyProgrammer – Reddit
- Python Challenge
The course also has a great community, so I highly recommend checking it out.
In the past year I had a pleasure working with a number of startups on improving their security posture. I would like to share some common pain points here and what to do about them.
Advising startups on security is not easy, as it tends to be a ‘wicked’ problem for a cash-strapped company – we often don’t want to spend money on security but can’t afford not to because of the potential devastating impact of security breaches. Business models of some of them depend on customer trust and the entire value of a company can be wiped out in a single incident.
On a plus side, security can actually increase the value of a startup through elevating trust and amplifying the brand message, which in turn leads to happier customers. It can also increase company valuation through demonstrating a mature attitude towards security and governance, which is especially useful in fundraising and acquisition scenarios.
Security is there to support the business, so start with understanding the product who uses it. Creating personas is quite a useful tool when trying to understand your customers. The same approach can be applied to security. Think through the threat model – who’s after the company and why? At what stage of a customer journey are we likely to get exposed?
Are we trying to protect our intellectual property from competitors or sensitive customer data from organise crime? Develop a prioritised plan and risk management approach to fit the answers. You can’t secure everything – focus on what’s truly important.
A risk based approach is key. Remember that the company is still relatively small and you need to be realistic what threats we are trying to protect against. Blindly picking your favourite NIST Cybersecurity Framework and applying all the controls might prove counterproductive.
Yes, the challenges are different compared to securing a large enterprise, but there some upsides too. In a startup, more often than not, you’re in a privileged position to build in security and privacy by design and deal with much less technical debt. You can embed yourself in the product development and engineering from day one. This will save time and effort trying to retrofit security later – the unfortunate reality of many large corporations.
Be wary, however, of imposing too much security on the business. At the end of the day, the company is here to innovate, albeit securely. Your aim should be to educate the people in the company about security risks and help them make the right decisions. Communicate often, showing that security is not only important to keep the company afloat but that it can also be an enabler. Changing behaviours around security will create a positive security culture and protect the business value.
How do you apply this in practice? Let’s say we established that we need to guard the company’s reputation, customer data and intellectual property all the while avoiding data breaches and regulatory fines. What should we focus on when it comes to countermeasures?
I recommend an approach that combines process and technology and focuses on three main areas: your product, your people and your platform.
Think of your product and your website as a front of your physical store. Thant’s what customers see and interact with. It generates sales, so protecting it is often your top priority. Make sure your developers are aware of OWASP vulnerabilities and secure coding practices. Do it from the start, hire a DevOps security expert if you must. Pentest your product regularly. Perform code reviews, use automated code analysis tools. Make sure you thought through DDoS attack prevention. Look into Web Application Firewalls and encryption. API security is the name of the game here. Monitor your APIs for abuse and unusual activity. Harden them, think though authentication.
I talked about building security culture above, but in a startup you go beyond raising awareness of security risks. You develop processes around reporting incidents, documenting your assets, defining standard builds and encryption mechanisms for endpoints, thinking through 2FA and password managers, locking down admin accounts, securing colleagues’ laptops and phones through mobile device management solutions and generally do anything else that will help people do their job better and more securely.
Some years ago I would’ve talked about network perimeter, firewalls and DMZs here. Today it’s all about the cloud. Know your shared responsibility model. Check out good practices of your cloud service provider. Main areas to consider here are: data governance, logging and monitoring, identity and access management, disaster recovery and business continuity. Separate your development and production environments. Resist the temptation to use sensitive (including customer) data in your test systems, minimise it as much as possible. Architect it well from the beginning and it will save you precious time and money down the road.
Every section above deserves its own blog and I have deliberately kept it high-level. The intention here is to provide a framework for you to think through the challenges most startups I encountered face today.
If the majority of your experience comes from the corporate environment, there are certainly skills you can leverage in the startup world too but be mindful of variances. The risks these companies face are different which leads to the need for a different response. Startups are known to be flexible, nimble and agile, so you should be too.
JSON Web Tokens (JWTs) are quickly becoming a popular way to implement information exchange and authorisation in single sign-on scenarios.
As with many things, this technology can be either quite secure or very insecure at the same time and a lot is dependent on the implementation. This opens a number of possibilities for attackers to exploit vulnerabilities if this standard is poorly implemented or outdated libraries are sued.
Here are some of the possible attack scenarios:
- A attackers can modify the token and hashing algorithm to indicate, through the ‘none’ keyword, that the integrity of the token has already been verified, fooling the server into accepting it as a valid token
- Attackers can change the algorithm from ‘RS256’ to ‘HS256’ and use the public key to generate a HMAC signature for the token, as server trusts the data inside the header of a JWT and doesn’t validate the algorithm it used to issue a token. The server will now treat this token as one generated with ‘HS256’ algorithm and use its public key to decode and verify it
- JWTs signed with HS256 algorithm could be susceptible to private key disclosure when weak keys are used. Attackers can conduct offline brute-force or dictionary attacks against the token, since a client does not need to interact with the server to check the validity of the private key after a token has been issued by the server
- Sensitive information (e.g. internal IP addresses) can be revealed, as all the information inside the JWT payload is stored in plain text
I recommend the following steps to address the concerns above:
- Reject tokens set with ‘none’ algorithm when a private key was used to issue them
- Use appropriate key length (e.g. 256 bit) to protect against brute force attacks
- Adjust the JWT token validation time depending on required security level (e.g. from few minutes up to an hour). For extra security, consider using reference tokens if there’s a need to be able to revoke/invalidate them
- Use HTTPS/SSL to ensure JWTs are encrypted during client-server communication, reducing the risk of the man-in-the-middle attack
- Overall, follow the best practices for implementing them, only use up-to-date and secure libraries and choose the right algorithm for requirements
OWASP have more detailed recommendations with Java code samples alongside other noteworthy material for common vulnerabilities and secure coding practices, so I encourage you to check it out if you need more information.
This is one of these blog posts with no content. I just really wanted to share some pics from one of the coolest cities I had a privilege to live and work in for the past few months.
Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.
OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.
Below is an excerpt from the Standard related to the authentication verification requirements:
The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.
If you want to learn more about biometric authentication, the best place to start is FIDO Alliance. Regardless of where you stand when it comes to passwords (are they obsolete and must be eliminated?), their standards and specifications can be useful.
The ecosystem enables enterprises and service providers to deploy strong authentication solutions that reduce reliance on passwords and protect against phishing, man-in-the-middle and replay attacks using stolen passwords.