RSS
Sorry for the long delay between posts, but last couple of months where quite hectic.
We started a new initiative called S³ Team. More information for it could be found on http://s-3.team
You can book a one-on-one meeting on https://calendly.com/gospodin_bodurov/one-on-one
Thank you and stay tuned for more!
I started wondering how people can prepare themselves for such times, given the recent events. Military clashes are happening in the real world and the cyber one in modern times. The are many parallels between defending assets in both of these worlds. In this article, I shall try listing the different approaches one could use to harden their defenses. At the same time, I shall try giving a clear picture of the target goals of the defenders.
So what is the ultimate goal of every defender? By default, it is to make the cost of the attack too high, and this way to diminish the gains of that attack. This kind of narrative is often seen in many books focused on the defensive side of cybersecurity. It is important to note that sometimes, people attack other people for personal reasons or even because of emotion. In these cases, attackers usually do not care how much it will cost them to perform the attack. As a defender, we should consider these reasons during the design phase of our defense.
There is one exciting proverb regarding the importance of preparation – more sweat in training, less blood in the fight. If we transfer this to the realm of cyber security – the more efforts we put into preparing the infrastructure, the less likely it is to be penetrated. So how we can prepare ourselves for an attack:
In conclusion, preparation for any defense activity comes with a lot of research. The primary goal of every defender is to increase the cost of attack. The higher the price is, the less motivated the attacker will be. Often the resources of both sides are asymmetric, and thus, some defenders must think such as guerilla fighters or even as Start-Up owners. They have to squeeze the last piece of efficiency provided by their infrastructure.
These days, many articles explain how people must have a side hustle and create multiple income sources. Unfortunately, one significant disadvantage of this media is that it does not successfully demonstrate how to build such a side hustle. It does not list the disadvantages and sacrifices coming with having such. And finally, it does not explain how to create a team working on that side hustle. This part will address these challenges and describe how our hypothetical team can resolve them.
But let’s start with listing the main disadvantages of having a side hustle:
After listing all the most critical disadvantages, let’s see how our hypothetical team can overcome them. The mandatory requirement for a moderately successful side hustle is to have at least ten hours per team member per week. In real life, if one of the team members can not dedicate such an amount of time per week, the setup becomes fragile, and there is a high chance of disaster. Having this prerequisite fulfilled, our fictional group could use the following mechanisms to improve their efficiency:
We shall have three back-end devs, one front-end/designer, and one dev-ops member in our hypothetical team. They will dedicate ten hours per week to the project, and one of the back-ends will be the squad leader. Every two weeks, they will have a two-hour call to discuss the current status and decide what they will do next. Additionally, they will use Slack, Github, and GSuite for synchronization.
In conclusion, I would emphasize taking the upper statements with a grain of salt. They helped me in my previous experiences. I have used side hustles from an early age to keep myself in shape and learn new skills. For example, I took my bachelor’s and master’s degrees and worked full time simultaneously. However, such dynamics will take their toll on most people quickly and could even lead to burnout or diseases. Given that, I would advise you to choose your teammates carefully – not everyone is “crazy” enough to live such a lifestyle.
In the following weeks, I shall write a couple of blog articles focused on how you can build a fictionary technical product on an extremely tight budget. The product will be defined as a side hustle, which idea will be to restructure, rewrite, and put into a modern shape an old project. We shall try minimizing the amount of time and money spent on the product because side hustles do not pay bills most of the time. At the same time, the approach will show how little is needed for a technical team to create a product and release it.
But what will be the idea – A simple tool that improves the way users plan their work. There are tons of such solutions on the market, and big companies have been developing something like that since the 90s of the last century. Keeping in mind that – we would like our fictionary product team to use new work approaches, check whether they can form a highly effective team, have some fun and focus their attention on something constructive. Of course, in reality, there will be no chances of scaling such a project. In addition, side hustle teams lose their energy and motivation to work long-term. In real life, people shift priorities – they can start working at a big corporation. Some had to focus on their income sources. Others got kids.
Such a mental example could be beneficial for every technical team despite these facts. In our fictional situation, the team will manage to make an initial version of the tool; make a website; produce a video; write a couple of technical whitepapers; create “branding” elements, and improve their skills during the period.
In the following parts of this series, I shall explain and discuss how this team will manage to achieve all of this in their “free” time and how much it will cost them in terms of money. Every part will be focused on one of the following items – branding elements, website, video, technical whitepapers, and finally, team structure and way of work. Hopefully, this will help you build your product and structure your team using the same tools and approaches.
The last article discussed the advantages and disadvantages of the Open Source software model. We even listed some uncomfortable truths regarding its economic viability and how it could be more expensive than many proprietary products. Despite being an Open Source zealot, I want to start with the statement that I still think proprietary software is sometimes better than Open Source ones. We can not compare my case with the average customer because I have spent the last 18 years working in IT – aka I want much more control over my system than the standard PC user. At the same time, when I can, I strongly avoid using proprietary software because I want to know what runs on my device or have the ability to review it if I wish. But let me list the good, the bad, and the ugly of using proprietary software:
The good
The bad
The ugly
In conclusion, there is no significant difference between proprietary and Open Source software models. The only meaningful difference is that customers could legally claim stuff easily from smaller proprietary vendors. However, once the vendor becomes too big, they hire better lawyers, and experienced lawyers are pretty good at defending corporate interests. Other than that, the tradeoff for the end customer is first-level support versus free usage.
I want to start this post with the statement that I am a fierce supporter of Open Source, and all of my computers, servers, and smartphones are using different flavors of Linux. For the last ten years, I have used Windows ten times at most, all of this because some software vendors have been neglecting the Linux ecosystem for years. Other than that, I have no wish or necessity to touch Mac or Windows for anything rather than testing web or mobile apps.
At the same time, I want to strongly emphasize that Open Source as a model has its problems and that I believe no software development practice, Open Source or proprietary, is ideal. This post aims to list some of the advantages and disadvantages the Open Source model has. Despite its widely successful spell during the last 30 or more years, the model is somehow economically broken. But, let’s start with the lists:
The good
The bad
The ugly
In conclusion, Open Source is not for everyone. It could be more secure or with better support, but only if the code comes from a reputable software vendor. In all other cases, the user is left on its own to handle their security and support. Another question is whether the alternative (using only proprietary software) is better, but I will analyze this in another article.
In the last part discussed the difference between an idea and a patent and how the proper judgment of whether something is in breach of the intellectual property is a gray area. Additionally, we spent some time analyzing the way software companies make an idea to product. We pointed out that all companies usually use already established algorithms and design patterns free of copyright. In this part, we shall discuss some techniques and pain points Start-Up founders must be aware of.
First – this advice is more oriented towards every entrepreneur – please make sure you hire a good lawyer before you do a single step of your Start-Up journey. And by good, I mean a lawyer with good work etiquette and a moral compass between wrong and right. Additional experience in the field is a bonus, but it must not be the main reason you start working with someone. Additionally, a skilled lawyer can help you set up your company in a way, which can save you many troubles in the future.
Second – make sure that you have at least one technical person with legal knowledge. This person will work closely with your lawyer when you have to make a legal decision regarding your technical product and will clear technical details regarding your contract templates, customer complaints, and, in the worst case, if someone decides to attack your organization legally. Ideally, this person must be part of your founding team but not hired.
Third – be paranoid. Contracts are invented for both sides to have the worst-case scenarios covered. And by that, we mean the worst-case scenarios indeed. Some examples are death, theft of intellectual property, not honoring the deal from one of the sides, etc. I can give you some tips: make sure you have every exit situation covered; the contract must have a period and if there is a penalty rule, make sure that there is an upper limit for it.
Fourth – make sure you don’t make enemies. A significant percent of legal arguments are because of personal reasons. The most common cause is that someone’s ego is hurt so much that this same person decides to take legal action. From a business perspective, usually, the main reason is that one of the sides chose not to honor their deal and pay some money. Sometimes the cheating side could even fabricate a whole story to get away from court action.
In conclusion, please make sure you treat your customers, partners, and employees well. Not honoring a deal must be triggered only by terrible reasons, which are out of your control. It is the only way your reputation will stay intact, and you will not make yourself a bad name. From my experience, I can give you an example where not honoring the initial deal led to the company losing all of its technical team and a delay of at least two years. Eventually, the company bankrupted.
During the years, I have seen many Start-Up team members lacking the necessary legal knowledge to make effective decisions about what is wrong and what is not wrong to do when working in that field. Many company owners have a too dark and or too light perception regarding the legal requirements when building a new technology-based company. At the same time even more significant number of company owners directly ignore some laws or try bending them to their benefit. As always, the truth is in the middle, and reality is more grayish.
But let’s start with a simple example regarding copyright laws. I am amazed how many people in technology still neglect them and even have no idea how they work. So let’s give them a ride. In their essence, these laws state the following:
In conclusion, the answer to these questions usually is – It depends. Every situation is different, and that’s the reason we have courts for making decisions. Laws typically try following the community’s moral compass; unfortunately, this is not always possible. It is a good idea for us as entrepreneurs to be prepared for any situation using that knowledge. And the list of bad situations includes legal, financial problems, and even personal vendetta from ex-partners and ex-employers. People change with age, and sometimes these changes are for the better, which is why contracts were invented.
In the last couple of months, we discussed how you could achieve a good level of personal security for your team members. We covered the topics of physical information security, home network security, and finally, your hardware devices cybersecurity. With this article, we shall cover the issue of how you can upgrade your cybersecurity defenses as a team. The article will cover the necessities of remote-first groups because they are harder to defend. You can use the same approach to protect your office or shared space-based team. Still, the focus will be on underfunded small groups. At the end of the article, I shall present a sample budget for your team infrastructure.
But before going to the budget, let’s analyze how a remote team of workers communicates and collaborates. I shall list down the different infrastructure requirements for a technical IT team. Keeping in mind how digitilized our World is, they will work fine for any other distributed team.
Communication Channels
For every remote-first team, it is essential to have a communication channel. We can categorize the different communication channels by their speed. But let’s do this in the following list:
Information Storage and Sharing
These days everything is done using information and files. But, you must store these files first and, after that, share them with your team members. Doing this using the standard communication channels is no good because there are no excellent categorization and tagging tools implemented in these systems. In short, they are not appropriately tailored for this kind of activity. That’s the reason the IT industry created a good amount of tools for solving this problem. Our small team will use them as well. So let me list them:
As we already discussed in the upper paragraphs, you need at least these six types of systems working and secured to have a functional remote-first team. Coming back to our knowledge of network defenses, the ideal solution for these systems is to be defended by VPN or a similar solution and expose only port 25 of the email server to support external communication.
Unfortunately, this kind of setup will be possible only if you deploy the services in your infrastructure. In the case of cloud providers, you don’t have much control of what is exposed to the Internet and how the cloud provider takes care of your security. Plus, the infrastructure is shared between multiple organizations, and there is no guarantee that these organizations follow such strict cybersecurity rules, such as your team.
Budget
But anyway, let’s create a budget for on-premise deployment of your infrastructure, and we shall use a VPS provider because it will be cheaper for us. A virtual private server runs its copy of an operating system (OS). Customers may have super user-level access to that active system instance, so they can install almost any software that runs on that OS. For many purposes, it is functionally equivalent to a dedicated physical server and, being software-defined, can much more easily be created and configured.
The most famous VPS providers are Amazon Web Services and Microsoft Azure. Still, there are some smaller players, such as Digital Ocean and Hetzner. As we shall do the infrastructure for a small team, we shall need a VPS with a not big pool of resources and go for the lowest price, which means CX1 instance in Hentzer. So let’s list now the different servers we shall need. All the prices are per month.
With a total budget of around 23.59$ per month, we achieved a pretty good level of security. Still, a determined attacker can penetrate this setup, but it will take him more time and resources. We shall use the standard VPS provider firewall. Still, if we want to achieve a higher level of security, we could add a server that will serve as a software-based firewall and IPS solution. Additionally, there are Open Source solutions for all the services types, and they will cost us 0$ per month.
In the last article, I shared the usual disadvantages when teams use agile methods in early Start-Ups. In this part, I shall give you my list of modifications and changes over the standard agile workflows. All of them are based on my experience and errors accumulated during the years working in underfunded Start-Ups. Additionally, I shall give you additional information regarding how it can affect team morale and motivation for every modification. But let me list the different changes I used during the years:
In conclusion, these are my leading suggestions for every early-stage Start-Up team. To extend your Start-Up life, you should cut time and resources from every non-essential part. My proposed list gives some hints in that direction, and I am sure you could create your lists by filtering what the essential and not the essential activities in your team are.
