Least Authority helps others improve their technologies to be more secure. We provide security consulting services for building and managing more secure systems from the design phase through the production launch.
Our consulting services include:
Generally, we focus on projects that fall into the following categories:
During our audits, we look for both common security vulnerabilities and specific attack vectors for your particular threat model. We are open to discussing various consulting approaches to meet the needs of your project.
In our source code audits, we look at existing codebases for potential security vulnerabilities in both design logic and actual implementation. These reviews are usually done before major code releases or significant milestones in a project roadmap.
We like to work with a transparent process and make our reviews a collaborative effort. The goals of our security audits are to improve the quality of systems we review and aim for sufficient remediation to help protect users. The following is the methodology we use in our security audit process.
In manually reviewing all of the code, we look for any potential issues with code logic, error handling, protocol and header parsing, cryptographic errors, and random number generators. We also watch for areas where more defensive programming could reduce the risk of future mistakes and speed up future audits. Although our primary focus is on the in-scope code, we examine dependency code and behavior when it is relevant to a particular line of investigation.
Our audit techniques include manual code analysis, user interface interaction, and whitebox penetration testing. We look at the project's website to get a high level understanding of what functionality the software under review provides. We then meet with the developers to gain an appreciation of their vision of the software. We install and use the relevant software, exploring the user interactions and roles. While we do this, we brainstorm threat models and attack surfaces. We read design documentation, review other audit results, search for similar projects, examine source code dependencies, skim open issue tickets, and generally investigate details other than the implementation. We hypothesize what vulnerabilities may be present, creating issue entries and proposed remediations or mitigations.
We follow a conservative, transparent process for analyzing potential security vulnerabilities and seeing them through successful remediation. Whenever a potential issue is discovered, we immediately create an issue entry for it in our report, even though we have not yet verified the feasibility and impact of the issue. This process is conservative because we document our suspicions early even if they are later shown to not represent exploitable vulnerabilities. We generally follow a process of first documenting the suspicion with unresolved questions, then confirming the issue through code analysis, live experimentation, or automated tests. Code analysis is the most tentative, and we strive to provide test code, log captures, or screenshots demonstrating our confirmation. After this we analyze the feasibility of an attack in a live system.
We search for immediate mitigations that live deployments can take, and finally we suggest the requirements for remediation engineering for future releases. We expect our mitigation and remediation recommendations to be scrutinized by the client developers and deployment engineers, and successful mitigation and remediation is an ongoing collaborative process after we deliver our report, and before the details are made public.
An Initial Audit Report will be provided after the initial review and a Final Audit Report will be provided at the conclusion of the verification phase of the project. Throughout the project we will hold meetings and share notes as is appropriate, depending on the process and focus of the investigations. These deliverables could also include code suggestions, instructions, or other forms of supporting material.
With specification and whitepaper reviews, our team performs a general review for design comprehensiveness, along with focusing on details that make these documents more effective at their purpose. This includes looking for basic technical details that would likely result in a rational implementation and an analysis of the Blockchain or token functions (if applicable) within the larger system and how various parties interact with these mechanisms for incentives. Importantly, we also do a security review of the system's design with a focus on data confidentiality and system integrity
The following is the methodology we use in our specification and whitepaper review process.
We start this project with a conversation to get an overview of the system and service offered from the perspective of the company and the technical design leads. We read the whitepaper, specification, design documentation, review other available resources, and generally analyze for any issues that may be present, according to our areas of concern. We will log our efforts to find vulnerabilities and related potential issues. After we wrap up our review work, we document any unresolved issues or open questions and suggested resolutions in the summary. This feedback summary is intended for internal use, only. A meeting to discuss the results of the report is recommended.
After delivering the summary, we will be available for consultation about remediation, as needed. The modification recommendations should be scrutinized by the client team as part of an ongoing collaborative process. When the client team believes that all issues with sufficient impact have been addressed, we will review the updated specification or whitepaper to confirm that these changes are made. It may be the case that some resolutions need to be discussed further because of the nature of the design, code, operational deployment, and other engineering changes, as well as mistakes or misunderstandings.
Finally, we will update our summary to reflect the new status of any issues in the initial summary. We will collaborate with the client team to make sure we all can agree that the summary is helpful for the client team to proceed into their next project phase. This summary can be written for internal use or external publishing, as discussed in the project planning phase.
An Initial Feedback Summary will be provided after the initial review and a Final Feedback Summary will be provided at the conclusion of the modification and verification phase of the project. Throughout the project we will hold meetings and share notes as is appropriate, depending on the process and focus of the investigations. These deliverables could also include other suggestions, instructions, or other forms of supporting material.
We provide consulting on how projects can take a Security by Design approach. We can advise on how a project can take security into consideration through each phase of the software and hardware lifecycle. This methodology helps to ensure protection against threats and vulnerabilities and minimizes the potential of malicious attacks against users and protects user data privacy. We can do this by partnering with a client to make an assessment of the current approach and recommend how to better integrate security considerations into the development processes, roadmap, and overall mission of a client project.
We provide consulting services to help to ensure the following security-related elements are considered in the design of a client project:
Least Authority takes a flexible and adaptable approach to each of our projects and each of our clients. Whether we’re providing comprehensive security consulting, conducting a security audit, or reviewing a specification or whitepaper, we use the following process phases for the different types of projects as a tool to help guide us, our clients and partners, and our projects - but understand that each project is unique and requires us to think outside of the box. While we are supporters of privacy and respect our clients needs for confidentiality, we also believe that transparency is powerful and necessary to empower users. We try to follow industry best practices, take seriously our role in the privacy and security community, and strive to take an ethical approach to notifying, resolving and disclosing issues to both our clients and their users.
After we have been contacted by a potential client, we evaluate our suitability for the proposed project. We believe it is important for us to deliver quality consulting to our clients and we are happy to make referrals to other firms and services.
After speaking to potential clients to learn more about the security needs and threat model, we develop a project proposal for our security consulting engagement. In the proposal we define the project scope, areas of concern, and propose a timeline and budget for the project.
Following introductions, we begin a requirements gathering and discovery phase so that we can better understand the project scope, areas of concern, and define the timeline needs and delivery expectations. This also gives us the opportunity to determine the necessary details of our process, discuss methods of communication and collaboration, provide insight into the our process and final deliverable, and answer any questions.
We like to start our projects with a kick-off meeting to get an overview of the service from the perspective of the company and the technical leads. Throughout the project we will hold meetings and share notes as is appropriate, depending on the process and focus of the investigations. After delivering our reports, we think it can be helpful to have a meeting to discuss the results of the report and we make ourselves available for consultation, as needed. Our recommendations should be scrutinized by the design, developers and deployment engineers, and successful mitigation and remediation is an ongoing collaborative process after we deliver our report, and before the details are made public.
After verification is completed and the Final Report is delivered, the team will publish an overview report that will be posted on the Least Authority website blog along with the Final Report. The project overview and Final Report may also be posted on our clients’ website if the client chooses to do so. Both teams will have an opportunity to review the summary post before it is published. Only after we agree with the client team that all vulnerabilities with sufficient impact have been appropriately mitigated do we publish our results.
At Least Authority, we work with our clients to make sure we all can agree that the report is appropriate to share publicly, but still transparent about and true to our original findings. We’re committed to our clients and will work to ensure companies have the appropriate information and time needed to address threats and vulnerabilities identified during our initial audit. In an effort to stay true to our mission of promoting ethical practices as it relates to security and privacy, we like to finish our work and take seriously our shared responsibility to the community utilizing the tools and technologies which we review. For this reason, Least Authority aims to see our projects through to completion and finds tremendous value in issues being addressed and made public in a timely manner when and where applicable, to ensure we are consciously contributing to the open source community. We find it particularly helpful to commit to a timeline for project completion that is best suited for our clients and the community which values the secure technologies that our clients provide.
Get in touch with us! Send us a message to contactus[at]leastauthority.com and if we think we can help you, we will reply to schedule a chat as soon as possible.
If you’d like to make the process more efficient, you can respond to the following questions in your initial email to help us better understand your needs: