New Year is coming, and usually, during this period, people assess what they did during the previous year. As a person with skills and experience in the defensive part of cybersecurity, I am always quite sensitive about sharing information, contracts, and legal documents with anyone, including institutions. During the last year on multiple times, I had to present official documents and explanations of why and how I did something. On one of the occurrences, I had to deliver around 20, again 20 papers to prove my right. Some of the documents did not relate to the right I wanted to execute, but the institution tried to enforce on me their policy. The representatives in the office even told me that I should trust the institution and that this was the first time someone asked for their data retention period, how they will assure that they will destroy the documents after that period and why they need the data at all.
During the last year, all of these experiences triggered the following questions in my mind – Is my data safe in any institution? Will it be in a safer place if I take care of my data, but not an institution? Can an ordinary person achieve a better level of security than an institution?
For all of these questions, the answers are usually – it depends on the level of expertise of the defending side. So it largely depends on the professionals the institution hired. To strengthen my statement, I can list several case studies that showed how attackers could penetrate even institutions and leak data:
Bank Hack: During a regular penetration testing exercise, a team of white hats managed to penetrate multiple office branches of a substantial French bank. Only in one of the offices did the employees ask the penetration expert to identify himself and ask the headquarters whether they sent anyone.
Government Taxes Authorities Hack: A couple of years ago, a hacker managed to leak multiple gigabytes of data from the Bulgarian Taxes Agency. The security hole had been opened for an extended period, reported numerous times, and no one took action to close it.
Universities Hack: At the beginning of 2021, multiple US universities, including members of the Ivy League, were hacked, and the personal information and documents of their students, lecturers, and professors were leaked to the public.
In conclusion, I think we could safely assume that taking care of our data is our right and responsibility. I am happy to delegate this responsibility only to legal professionals (lawyers, notaries, and judges). They work with confidential documents every day and know how a data leak can affect people. In any other case, sharing data with 3rd parties must come with at least a declaration for their data retention practices and how they destroy the data (there are security practices for doing that correctly).
And this is the last article on cybersecurity tactics for small teams series. We have already finished the hardware computer-based parts, and I shall use this last article to cover more the social side of cybersecurity. We shall spend the following paragraphs speaking about your organization’s public image and how it can be affected by your cybersecurity defenses. At the end of the article, we shall present a summarized budget using all the budgets we created during the last couple of months. So let’s start.
During the last decades, we witnessed the rapid growth of various social media platforms. These days every organization has to show a stable social presence to improve its marketing. It is fascinating how virtual space can reflect on real people and places with its data and information. Having this in mind, we have to treat all the social accounts of a given organization as assets, and by assets, we have to find a strategy to keep them safe and secured.
Imagine what will happen if an attacker takes control of your team accounts. Usually, these accounts are used to have private chats with clients or customers in different social media systems. Data dump consisting of such talks can sometimes be quite hazardous to your organization.
Internal Team Communication
As we discussed in the previous article, teams must communicate. In remote-first groups, this communication must happen in some virtual place, where team members can coordinate and write. By default, every email server, chat server, and video conferencing server record things into a historical log. It is essential to take into account that these logs are information and company assets.
Sometimes the tone there is inappropriate, and thus dumping them over the Internet can cause significant problems to your organization. It is essential to understand that a cultural change must happen to make your organization understand the effects such an attack can have.
Unfortunately, with the rise of digitalization, the following tendency started to emerge – your personal digital life can affect and hurt your professional one. It means you have to be aware that simple private communication can be leaked and can cause tremendous problems to your persona and your organization.
Influencer economy and personal branding changed over the Internet during the last decade. Despite its asymmetric nature, the personal brands managed to keep going with the big enterprises. It is more and more common for companies to start using their employees’ brands to promote themselves. Which, in short, we can phrase as an asset’s loan. Employees loan out their assets to their employer during the period of working together. From a cybersecurity point of view, your organization must understand that now you defend company infrastructure and personal ones.
Now, after we covered the effects that public image can have on your organization, it is a good idea to cover how you can defend yourself from penetration:
Security awareness course: A good security course will cover all these topics and many more. Still, it is good to touch some information security, not only cybersecurity topics, during the period. I would advise you to search for vendors providing information security business-based courses.
2FA: Especially for an account that is not part of your infrastructure, a 2FA is a must, including the organizational accounts and the personal accounts.
Personal Development: Personal development of your team members can help a lot to avoid such attacks. There are multiple use cases and stories on the Internet from which you can take inspiration.
As we already discussed in the final paragraph of this article will be a combined budget from all the previous articles together with this one. The budget will have two categories – per team and person. The per team will be for your whole team, and per person will be for one team member. The budget will be for two years because this is the service life of most of the hardware equipment. The team will be five people. So let’s do it.
Hardware toolkit (100$)
Paper Shredder (50$)
Camping Gear (50$)
Office Security System (4000$)
SIEM System (0$)
Email And Chat Server(85.68$)
Video Conferencing Server(85.68$)
Security Awareness Course(1000$)
Total per team: 6266$
Group Policy Server (150$)
Pacsafe Backpack (190$)
Business Series Laptop (1000$)
Laptop Operating System(0$)
Total per team member: 5 x 1870$ = 9350$
With a total budget of around 15616$ for two years, 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. The budget is almost less than 3300$ per team member and around 140$ per month.
And this brings our series to an end. I hope you enjoyed our journey, and in case of questions, you can always book a session with me. I shall be more than happy to answer.
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:
Ideas: Ideas are free from copyright. However, here come two questions regarding that statement. First – how do we distinguish an idea from something else? We usually use already established design patterns and algorithms in technology and try to model our ideas using these tools. So, in short, the standard approach of making your concept alive is to use something someone has already invented, but it is not under copyright. Second – having in mind the last sentence, where is the line between an idea and something which must be under copyright? Should we claim the collection of algorithms and design patterns needed for one idea’s implementation to be under copyright?
Patents: For anyone reading patent papers, patents describe the design patterns and logic implementing the idea defended by the patent. At the same time, we could ask the following questions: What happens if we change one of the boxes used in the patent and implement it another way, but not the one described in the patent? Will this invalidate the patent? Will this be enough legally to claim that our Start-Up does not use the patent?
Programming code: By default, every programming code is under copyright. The idea of this setup is to defend the employer legally. However, there are some exceptions for that – what happens if the employee is an outsourcing company or freelancer? What happens if the employee uses a code or skills acquired before starting working with the employer? What happens if the employer has permitted the employee to operate its own company and projects in the same industry? What happens if there was a verbal agreement for partnership between the employer and the employee, but the employer decides not to honor the deal?
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.
Several months ago, I had to make a trip over the weekend to a city sitting 160km far from Burgas. I decided to take the more direct route, which goes through Stara Planina, one of the mountains located in Bulgaria. There were many trucks on the road. Other car drivers and I were driving behind them without a clear opportunity to overtake. I wanted to check something on my smartphone, and I misclicked on the WIFi network indicator. To my surprise, the list showed one item – a WiFi network with a mobile phone number as its name.
And then it clicked in my mind that the two cars in front of me, trying to overtake the truck for the last twenty minutes, were most probably a company traveling together, and the owner of one of the cars was sharing his/her hot spot with the passengers. He/She had most likely decided to name his/her WiFi network with his/her mobile phone number.
The defensive cybersecurity expert in me started clicking with his tongue in disapproval because I now had the driver’s phone number and his/her car registration plate. Additionally, I had the knowledge that someone in the cars in front of me was using the listed WiFi network. With all that information, a motivated attacker could do the following exciting things:
Find the driver of the car: With some search in the dark web, a motivated attacker could find illegal databases with phone numbers and vehicle registration plates mapped to their owners. Additionally, if the phone number owner had posted an online ad for something using that number, it usually got indexed by most search engines.
Get the metadata of the WiFi users: The WiFi search protocol is quite leaky in terms of metadata sharing. For example, your WiFi client usually broadcasts all the network SSIDs your device was connected to for the last couple of days. Using this weakness, we could collect that data for every device connected to the hot spot and use that data for malicious activities. One such activity is finding the places where the owner of any of the connected devices was. Especially if the owner of the devices regularly connects to public WiFi networks in hotels, cafes, etc. There are many databases in the dark and on the regular web with such mappings betweens WiFi SSIDs and GPS coordinates.
Enforce the WiFi client to connect to a malicious endpoint: With the proper equipment, the attacker could enforce all the WiFi clients to connect to his/her malicious WiFi endpoint and sniff all the data coming from the devices. Modern smartphones software usually comes with proper protection, but bugs happen, and the attacker could keep the collected data and decrypt it offline or in the future.
Social engineer the owner of the car: A motivated attacker could call the owner of the vehicle and present himself/herself as a police officer asking the owner where the car is at the moment and that someone made a complaint about the vehicle parked not correctly. To make the lie ever more truthful, the attacker could tell the driver that he/she and his/her colleague must go and check the car personally. If this attack is performed after work hours, the victim will probably give his/her an address near his/her home.
In conclusion, the car driver in front of me had a bit of good luck that I was driving behind them, but not a criminal. In another case, all of these attack vectors could happen. Unfortunately or fortunately, cars have become more and more intelligent. But with becoming more intelligent, more and more security holes have become open for attack. We should be concerned, especially with the increasing adoption of electric vehicles in our lives. They are, in fact, computers on wheels. And these computers have and will have more and more security vulnerabilities.
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:
Email: Email is usually categorized as an official communication channel, which we can use for communication inside and outside of your organization. It is heavily asynchronous, with messages response going from minutes to days. Usually, this kind of communication is used for strategic discussions and long-term plans. That’s the reason it could be the most valuable target for an attacker.
Online Chat: Online chats are a faster way of exchanging messages. Usually, they are used when you need a quicker response from your peer, and there is no good time for a short, not planned call. Usually, the rule of thumb is to spend no more than 15 minutes chatting, and if the issue is not resolved, move to something faster. This one will be the second most significant target after the email for an attacker.
Video Conferencing: This one is the fastest. Usually, it is used to exchange a burst of already prepared information. Most of the time, the data is a tactical one, and thus this way of communication is with the lowest priority for attackers.
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:
Project/Product Management System: Project management software (PMS) can help plan, organize, manage resource tools and develop resource estimates. Depending on the sophistication of the software, it can manage estimation and planning, scheduling, cost control, and budget management, resource allocation, collaboration software, communication, decision-making, quality management, time management, and documentation or administration systems. As you can see, most of the vital information for your project/product will be in this system, making it an excellent target for an attacker.
Cloud Storage Solution: Project management systems are outstanding in documentation storage, but they lack some of the features a full-scale cloud-based storage solution can offer. In this kind of solution, you usually store big files in a format such as video, audio, high definition graphics, etc. As such, you can leave a big part of your intellectual property lying in such cloud storage, making it a good target for an attacker.
Automation System: Especially in IT teams, sometimes your team will need automated jobs to happen. If you have automation specialists, know how to write scripts, you can automate a big part of your daily routes. In the case of programming teams, this is usually building, deploying, and testing procedures for a new version of your product/project. It means that you have to give access from your automation system to your programming code, for example. And this makes it an excellent target for an attacker.
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.
Email And Chat Server(3.57$): As there will be no significant demand for these two services, we can place them on the same machine.
VPN Server(3.57$): We shall have one machine for the VPN server, and all of the services without port 25 will be behind this VPN.
GitLab Server(3.57$): Gitlab is a project management/automation system. As it can become quite a hungry beast, a standalone instance is a way to go.
Video Conferencing Server(3.57$): One more hungry beast, it is a good idea to have it as a standalone server.
Cloud Storage(9.31$): This one will be a CX1 instance + an additional 100GB to store larger files. For a small team, a total of 120GB will be enough.
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:
Do not do peer reviews: Peer reviews work pretty well for improving code quality and knowledge sharing. However, they are one of the biggest bottlenecks in your team workflow. Additionally, to have productive peer reviews, the peers must usually be at the same level of expertise. The best case is for the reviewers to be with more considerable expertise than the reviewed. For early-stage Start-Ups, I would suggest senior management appoint two or three people to do all the code reviews in the company. With this approach, team morale and motivation will increase because you would avoid much friction and drama.
Avoid unit tests: Unit tests are one of the best ways to increase your code quality. However, during the early stages of your product, where you do a lot of research and expect significant refactoring of the code base, unit tests, constant maintenance can kill your velocity and hurt your team morale. Usually, after the initial effort to create the tests, the team stops maintaining them after a couple of tight deadlines, and finally, they are entirely disabled. Better spend your time doing integration, smoke, or component tests because they work on established APIs, and these APIs do not change dramatically.
Don’t be sloppy with your architecture: Make sure your technical architecture is solid and can be upgraded or refactored easily. Quality of code is not so important because you can improve your code quality quickly, but not your architecture. Many teams decide to start with less complex architecture, and after that, they have to reimplement the solution. Better, plan how you are going to implement your architecture in phases with change in mind. Start with only the essential components and upgrade them later. Doing something twice is the most significant morale and motivation killer in one team.
Do not estimate R&D: Early-stage Start-Ups usually must not plan research and development. It would be best to entirely avoid research and development and work on already established business or technical models with minor modifications. Innovation is expensive in terms of time and money. It should be avoided or minimized as much as possible.
Threat every task as a different sub-project: Many company owners love to categorize their products using the famous triangle of quality, speed, and time. However, the major mistake is that a software product is a collection of submodules. And every submodule comes with its complexity and implementation. It is much better to treat every submodule as a separate project and decide what we expect using the quality, speed, and time triangle.
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:
R&D: All of the listed methods work on the assumption that the team will not do any research and development. Aka, the business owners know their business niche and that someone else already did the R&D part. In reality, this rarely happens, except when we start a business without any innovation. When you want to make an innovation, all traditional product management frameworks stop working. Usually, in the Start-Up World, the team must do R&D and code writing simultaneously (investors and clients want to see progress).
Burnouts: Constant changes in business requirements and business situations usually involve many changes in the technology stack and your programming code. Sometimes you must rewrite the whole product from zero. And this typically takes its toll on the engineering team. For sure, if you do not manage to make business traction (aka finding clients) for the first three years of your Start-Up, it is virtually certain that this lack of progress will demotivate your technical team, and most probably some of the members will feel the effects of burnout.
The process will not mitigate your people’s weaknesses: According to most agile methodologies fans, these methods are the panacea for every technological problem. However, we have to ask ourselves why only 5% of the Start-Up technical companies pass the second year of work? All of them use these methodologies. For sure, we could blame the business development and marketing, and we will be right that 70-80% of one successful business is the way you sell. However, at the same time, I saw many technical teams struggling in their performance because of leaning too much on the agile principles.
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:
Microsoft Office and Outlook: LibreOffice is an excellent alternative for having an on-premise installation of the office software package. It usually has good compatibility with the original Microsoft Office and could open and edit files. Sometimes the styles of the original files are destroyed. In that case, one can use the cloud variant of Microsoft Office in a web browser. This way, we could avoid such issues. Additionally, Linux comes with Thunderbird, which is an excellent alternative to Outlook.
Zoom/Viber/Microsoft Teams/Slack: All of these have binaries for Linux, which means you could have the standard video conferencing apps installed on your machine and have the same experience as the Windows-native users. Additionally, they all support web browsers, which means no need for a native app for communication.
Exchange/Sharepoint: Most Linux distributions do not support an active directory out of the box. However, one German distro supported all the group policy features and made it possible for Ubuntu-based clients to connect to this active directory. The name of that distribution is Univention Corporate Server and could be used as a drop-in replacement for Windows Server.
Specialized Software: And usually, here comes the main problem with Linux. Most of the specialized software does not have builds for Linux. Some examples are Adobe Photoshop, Adobe Illustrator, 3D rendering software, most of the accounting software, most of the governments’ software, etc. Unfortunately, there are no signs of bringing this software to Linux soon. Fortunately, most of the workers in a given company do not need highly specialized software, and they could do their job in the web browser.
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.
In the last part, we finished the description of our network protocol and its advantages over other encrypted video streaming protocols. In this part, we shall discuss how we created our hardware prototype for the body camera system and what performance problems we had to resolve when we implemented the software part of it. At the end of the article, we shall show you how much our prototype costs and a sample budget for doing something similar.
But before that, let’s first see what our competition was and what features they had for their cameras.
Axon Body 2
The Axon Body 2 is a camera system incorporating an audio and video recording device. This camera is designed for use in harsh environmental conditions encountered in law enforcement, corrections, military, and security activities. The Axon Body 2 camera is designed to record events for secure storage, retrieval, and analysis via Evidence.com services. The recorded events are transferred to your storage solution via the Axon Dock or by using Evidence Sync software installed on a Windows computer.
HD Video and Dual Audio Channels: Record in low-light and HD, and make voices more distinct with automatic tuning and noise reduction.
Wireless Activation: Axon Signal reports events, like when you open the car door or activate the light bar, so your camera can start recording.
Wi-Fi & Bluetooth Connectivity: Use Wi-Fi to stream videos and Bluetooth to assign metadata.
Mobile App: Connect with Axon View to stream, tag, and replay videos from your phone.
Unmatched Durability: Handle in extreme weather and brutal conditions.
Full-Shift Battery: Record for more than 12 hours.
Axon RapidLock Mounts: Keep your shot steady with versatile mounts.
Motorola V300 Body Camera
This camera is built specifically for law enforcement. The V300 continuous-operation body-worn camera is ready to go when you are with its detachable battery, 128GB of storage space, wireless uploading, and Record-after-the-Fact® technology. Integrated with the technology you use daily to enhance your focus and combined with powerful device and evidence management software, the V300 body-worn video solution enables you to capture every encounter.
Detachable Battery: Easily change the V300’s rechargeable battery while on the go. Keep an extra battery at the ready for unexpectedly long shifts, extra shifts, or part-time jobs where a body-worn camera is required.
Natural Field of View: Eliminate the fisheye effect from wide-angle lenses that warps video footage. Our distortion-correction technology provides clear and complete video evidence.
Built-in Display: A clear LCD on the top of the camera allows easy viewing of device status.
Absolute Encryption: Elevate your data security with encryption at rest and in transit. The V300 guards your data and your reputation.
Rugged & Durable: Tested ruthlessly to survive in a public safety environment, the V300 is shockproof and waterproof to IP67.
Automatic Wireless Upload: Send critical video back to headquarters while still in the field. When docked in the car, the V300 body camera uploads to cloud-based or on-premise evidence management systems via wireless networks like LTE and FirstNet, anytime, anywhere.
During the time of development, these were the two main competitions. Both of them lacked the real-time streaming support we wanted. However, both of them had pretty exciting features, without which our solution would not have enough commercial traction.
After a good amount of market analysis and tests of different technologies, we decided our body camera system to have the following features:
Full-Shift Battery: Record for more than 12 hours.
Automatic Upload: Send critical video back to headquarters while still in the field.
LTE Real-Time Streaming: With adaptive bitrate, we could make our camera system send data during the whole shift.
Rugged & Durable: Tested ruthlessly to survive in a public safety environment
Built-in Display: A clear LCD in the camera system to allow easy viewing of system status.
Absolute Encryption: We wanted data security with encryption at rest and in transit.
Fisheye Field Of View: We wanted our camera system to support more than 100 degrees field of view.
Low Light Vision: Having in mind that most of the crimes happen during the night, we wanted this feature.
But we had a problem. Being a small, underfunded team located in Burgas, we did not have access to many hardware vendors, nor did we have the hardware team who could implement a body camera system from scratch. We had to take another approach. After a couple of weeks of analysis, we decided to implement a pluggable system using manufactured customer devices. The final system design consisted of the following components:
Android-based hardware device: For the last decade, almost all Android devices have supported USB On-The-Go. USB On-The-Go (USB OTG or just OTG) is a specification first used in late 2001 that allows USB devices, such as tablets or smartphones, to act as a host, allowing other USB devices, such as USB flash drives, digital cameras, mouse or keyboards, to be attached to them. USB OTG allows those devices to switch back and forth between the roles of Host and Device. A mobile phone may read from removable media as the Host but present itself as a (USB Mass Storage) Device when connected to a host computer. In short, we could attach a standard USB web camera to a typical smartphone.
Body mounted USB camera: Here, we had quite an interesting problem. Standard USB web cameras are not tailored for body mounting, neither are they durable enough. We spent a good amount of time checking how to solve this issue, and finally, we managed to find a suitable USB camera vendor using Sony-based camera sensors. The vendor could mount any lens to the camera sensor, and the whole board came with a good amount of mounting holes. After that, one of our hardware people designed a custom mountable case for our USB camera and 3d printed it.
New extended battery: The standard battery of our Android device was around 4100mah. Unfortunately, after multiple tests, we saw that with every needed hardware capability activated, aka LTE, USB OTG, GPS, and microphone, the Android device was taking around 800-900mah per hour. And this was not enough for the whole 12 hours shift. So we took the extraordinary decision of creating our battery. Finally, we managed to produce a proof of concept 12400 mah battery replacement for our Android device. And indeed, it took 12 hours to recharge.
Mount for cars and bicycles: We wanted our system to support multiple different mounting points. So, to allow this to happen, we bought standard multi-camera mounts for vehicles and bikes and created adapters for our 3d printed camera to enable attachment to the stock mounts.
UDP streamer module: This module’s main functionality was sending UDP packets and receiving answers for these UDP packets. It sent analytics data to the Adaptive bitrate control module to decide how to switch between different formats and resolutions.
Encryption module: This module was highly optimized to perform hybrid encryption and decryption of byte objects. We managed to optimize the performance, so the module supported encryption and decryption of real-time h.264 frames coming from the USB module.
Network protocol module: Main functionality here was to construct and decode UDP datagrams messages. It used the encryption module to encrypt the data before sending it to the UDP streamer.
Adaptive bitrate and codec control module: This module controlled what type of compression strategy to use to ensure that the headquarters will receive data no matter the LTE signal.
Objects pool module: The idea of the module was to reuse different bytes arrays during the lifecycle of the h.264 packets. With around 24 frames streamed per second, creating and destroying many bytes arrays would entirely kill our application.
USB camera module: This module wrapped the communication and handling of the USB video camera bus. The idea was to support multiple different cameras and formats here.
Telemetry module: In this module, we collected all the additional data we had – current battery consumption, remaining battery time, GPS coordinates, sd card storage, etc.
h.264 decoding module: This module’s main functionality was to transfer video frame data in a different format. For example, we supported h.264 frames, png, and jpeg formats. The application was intelligent enough to decide when to switch between the different formats.
We used Java and C++ programming languages for the implementation of all the modules. The only C++ part was the USB camera module because of the low-level communication with the USB bus.
Let me share some notes on why we decided to use an Android device. We could implement our body camera system using an ARM-based board with Linux installed on top of it. It would dramatically reduce our software efforts. However, from a hardware point of view, most ARM-based boards lacked good CPUs, battery support, and housing. Not to mention, the development of a custom ARM board was entirely outside of our budget. Fortunately, our software was designed this way, so we could easily switch the hardware platform in case of investment or more considerable client interest.
In conclusion, our body camera system managed to fulfill our initial requirements for MVP. It worked well, and we made multiple videos and streams testing it in various environments and locations. Our system even managed to send data through 3G mobile cells in areas where LTE/4G was not supported.
A sample video of how the system works could be found here