Sorry for the long delay between posts, but last couple of months where quite hectic.
Thank you and stay tuned for more!
Sorry for the long delay between posts, but last couple of months where quite hectic.
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:
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:
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 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.
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.
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.
I want to start these two articles by observing that I don’t believe agile methods are appropriate in their proper form for Start-Ups. In the first article, I will list most of the disadvantages of the agile methodologies and how they could hurt the Start-Up’s performance. In the second one, I shall present what worked for me in the past and what did not.
But let’s start with little history of the product management frameworks and how they evolved. Historically the initial management framework was the so-named waterfall or phased approach. With that approach, the companies copied how most engineering products are created by multiple phases and initial requirements gathering. This way of working does an excellent job when you want your solution to be installed on-premise and must work for a long time without interruption.
In the 80s of the last century, Watts Humphrey, during his work at Carnegie Mellon University, founded the Software Process Program, and with that, he started the so-named PSP (Personal Software Process). This process heavily relies on not comparing the performance between different developers but rather trying to improve every developer as a single unit. Additionally, in PSP, we have the notation of knowledge re-usage – aka if the developer has implemented something similar as a block in the past, we could expect him to implement such block with the same speed.
In 1986 Hirotaka Takeuchi and Ikujiro Nonaka started Scrum and the foundation of different agile methodologies. At its core, the agile development process defines that the “customer/client/company owner” will work together with the team and provide business knowledge and requirements weekly. A fundamental principle of Scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility) and that there will be unpredictable challenges — for which a predictive or planned approach is not suited. These changes come from various sources, but understanding why is irrelevant: change should be accepted, embraced, and analyzed for benefits.
And now here are some reasons they do not work well for complex Start-Ups:
In conclusion, I would want to emphasize that no product management workflow in the World will mitigate the weaknesses your team has in the first three years of your Start-Up. The only way to increase your team productivity is by training them, and by training, I mean the business and the psychological part of being into a Start-Up. Technical knowledge is much easier to adopt and realize than handling that your odds of winning a VC are 1:300.
For a long time, I had this discussion with colleagues and friends about whether open source technologies, especially Linux, could replace all of your software needs. In the past, the main problem regarding using Linux was not mature enough ecosystem and being too complex to work with. However, after the introduction of Android (we could categorize it as a Linux distribution), things became less difficult, and many companies invested much of their time into making their products work on Linux.
But still, something is missing. By official data, the Desktop Linux users are between 0.6 and 1.5% of the overall Desktop Users. And this is quite a low count of Desktop users. It seems free is not enough for business owners to make the shift. But let’s compare the traditional business software stack to what Linux can offer:
In conclusion, using Linux in the corporate environment has become more and more user-friendly. At the same time, I firmly believe that Linux could entirely replace the software stack for SMEs, excluding those using the specialized software. Fortunately, there is a shift in software development for going into the cloud, which could, even more, help the SMEs with the specialized software (some vendors are already moving their software in the cloud). Additionally, all Linux distributions support Firefox and Chrome out of the box. And as a final – during my coronavirus sick leave, I managed to open my X-Ray photos (DCM image format) on CentOS 8 (I have been using CentOS for the last up to 10 years) without installing anything. ImageMagick supported it out of the box.