통신은 사람이나 사물 간에 매체를 통하여 정보나 의사를 전달하는 것을 말합니다. 자동차 안에는 수많은 부품 및 제어기들이 있습니다. 엔진을 제어하는 ECU (Engine Control Unit), 변속기를 제어하는 TCU (Transmission Control Unit), 각종 ADAS (Advanced Driver Assistance System) 관련 제어기 등 수십 개에 해당하는 제어기들이 차량에 장착되고, 제어기들은 서로 데이터를 주고받으며 공유된 정보를 통해 다양한 제어를 하게 됩니다. 데이터를 주고받을 때 제어기들 간의 규칙이 있어야 원활한 통신을 할 수 있는데, 이러한 규칙을 통신 프로토콜 (Protocol)이라고 합니다. 자동차 내에는 CAN (Controller Area Network) 통신, LIN 통신, LAN 통신 등 다양한 통신 방법을 용도에 맞게 사용하고 있습니다. 그중에서 CAN 통신이 자동차에서 가장 많이 사용되고 있습니다.
CAN 통신은 자동차 부품회사인 보쉬 (BOSCH)에서 개발된 차량용 네트워크 통신 방식으로, 전기적 노이즈 발생이 많은 자동차 환경에서 신뢰성을 확보하기 위해 개발된 통신 방식입니다.
CAN 통신은 여러 개의 제어기들을 병렬로 연결하여 데이터를 주고받는 구조로 되어 있습니다. 통신 라인을 공유하는 모든 제어기들이 마스터 역할을 하고 있기 때문에 필요에 따라 언제든지 통신이 가능합니다. 쉽게 말해, 통신선상에 데이터를 띄워 놓으면, 어떤 제어기든지 필요할 때마다 데이터를 가져가 사용하는 방식입니다.
여러 개의 제어기들을 병렬로 연결하여 데이터를 주고받는 구조
제어기 내부의 CAN 통신 회로 구성
제어기 내의 CAN 통신 회로 구성은 위의 블록도와 같습니다. 가장 오른쪽은 외부 CAN BUS로 CAN H와 CAN L 신호를 주고받습니다. CAN BUS는 제어기 커넥터를 통해 연결된 후 CAN 트랜시버로 연결됩니다. 그리고 CAN 트랜시버는 마이크로컨트롤러 (MCU)와 연결됩니다. 정리하면, MCU와 CAN BUS 사이에 CAN 트랜시버가 있는 구조입니다. 그렇다면 CAN 트랜시버의 역할을 간단하게 살펴보겠습니다.
먼저 CAN H와 CAN L의 파형은 아래 그림의 오른쪽과 같습니다. CAN H는 2.5V~3.5V 전압을, CAN L는 2.5V~1.5V 전압을 사용합니다. CAN H와 CAN L의 전위차가 없을 때는 recessive (열성), CAN H와 CAN L의 전위차가 있을 때는 dominant (우성)이라고 표현합니다. 즉, CAN 통신은 두 라인의 전위차를 통해 데이터를 전달하는 것입니다.
CAN 통신의 Recessive와 Dominant
CAN BUS의 CAN H와 CAN L 신호가 CAN 트랜시버를 통해 recessive 인지 dominant 인지 판단을 합니다. 그리고 CAN 트랜시버의 RX를 통해 recessive 이면 HIGH, dominant 이면 LOW 신호를 MCU에 전달합니다. 반대로 MCU에서 CAN BUS로 데이터를 전송할 때는 MCU의 LOW와 HIGH 신호를 CAN 트랜시버가 CAN H와 CAN L 신호 형태에 맞게 변환해 줍니다.
출처 : TEXAS INSTRUMENTS, Indtroduction to the Controller Area Network (CAN)
CAN 트랜시버 내부 회로도
위의 CAN 트랜시버 회로와 같이, MCU의 TX에서 HIGH 신호를 보내면 FET는 비활성화되어 2.5V 풀업 저항에 의해 CAN H와 CAN L 모두 2.5V가 됩니다. 반대로 MCU의 TX에서 LOW 신호를 보내면 FET는 활성화되어 CAN H 5V, CAN L는 GND 전위가 됩니다.
CAN 프레임 형식에 대해 간단하게 알아보겠습니다. 바로 아래 그림과 같이 CAN 통신에서 요구하는 CAN 통신 프레임을 만족해야 제어기들 간에 데이터를 전송할 수 있습니다. 쉽게 말해, 서로 데이터를 어떻게 주고받을지 약속을 정하는 것과 같습니다.
CAN 프레임 형식
SOF (Start of Frame)
메시지의 시작을 표시, idle 상태 이후 동기화
Identifier
메시지의 우선순위를 설정, 이진값이 낮을수록 우선순위가 높음
RTR (Remote Transmission Request)
데이터 프레임과 리모트 프레임 구분 (데이터 프레임은 0)
IDE (Idenrifier Extension)
CAN Standard 프레임과 CAN Extended 프레임 구분
R0
Reserved bit
DLC (Data Length Code)
전송 중인 데이터의 바이트 수
Data
8byte 데이터를 전송
CRC (Cycle Redundancy Check)
16bit checksum
ACK (Acknowledgement)
승인
EOF (End of Frame)
CAN 프레임의 끝을 표시
IFS (Interframe Space)
버퍼 영역
CAN 통신은 여러 제어기들이 신호를 함께 보내고, 이를 피드백 받으면서 진행됩니다. 하지만 동시에 여러 제어기들이 신호를 송신한다면 어떻게 우선순위를 정하는지 알아보겠습니다. 아래 표와 같이 NODE 3를 가지고 Idendifier의 비트를 비교합니다.
CAN 통신 arbitration의 원리
신호가 HIGH 이면 recessive, LOW 이면dominant 입니다. 위의 그림에서 10~6 bit 까지 3개의 NODE 상태는 모두 동일합니다. 5번 bit는 NODE 2만 HIGH (recessive)입니다. Recessive는 말 그대로 "열성"이라는 의미로 여기서부터 NODE 2의 신호 전송은 중지됩니다. 그리고 2번 bit에서는 NODE 1이 HIGH (recessive)입니다. 따라서 NODE 1의 신호 전송이 중지됩니다. 결국 여기서 우선순위는 NODE 3이 가장 높습니다. 중간에 전송을 중지한 NODE 1과 NODE 2는 다음에 재전송을 시도합니다.
※ CAN 통신에서의 에러
에러가 발생되면 에러 프레임이 전송됩니다. 에러 프레임으로 전송 실패를 인식하면 재전송의 기회를 기다립니다.
- BIT 에러 : 송신 bit와 수신 bit가 상이한 경우
- ACK 에러 : 수신 장치가 응답이 없을 때, 통신 선로가 끊기거나 접촉 불량인 경우
- FORMAT 에러 : CRC del, ACK del, EOF 영역에 0 (dominant) 값이 나타난 경우
- STUFF 에러 : Stuffing 규칙이 맞지 않은 경우
- CRC 에러 : CRC가 맞지 않은 경우
CAN 제어기 내부에는 송신 에러 카운터와 수신 에러 카운터가 각각 있습니다. 에러가 검출될 때마다 카운터가 1씩 증가하고, 에러 없이 성공적으로 전달이 완료되면 카운터가 1씩 감소합니다. 초기 상태에는 Error active 상태이며, 에러 카운터 값이 127 보다 커지면 Error passive 상태가 됩니다. 그리고 에러 카운터 값이 255를 초과하면 BUS OFF 상태로 해당 노드를 CAN 망에서 끊어버립니다.
The File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network. It is a plain-text protocol that uses as new line character 0x0d 0x0a so sometimes you need to connect using telnet or nc -C.
Default Port: 21
PORT STATE SERVICE
21/tcp open ftp
Connections Active & Passive
In Active FTP the FTP client first initiates the control connection from its port N to FTP Servers command port – port 21. The client then listens to port N+1 and sends the port N+1 to FTP Server. FTP Server then initiates the data connection, from its port M to the port N+1 of the FTP Client.
But, if the FTP Client has a firewall setup that controls the incoming data connections from outside, then active FTP may be a problem. And, a feasible solution for that is Passive FTP.
In Passive FTP, the client initiates the control connection from its port N to the port 21 of FTP Server. After this, the client issues a passv comand. The server then sends the client one of its port number M. And the clientinitiates the data connection from its port P to port M of the FTP Server.
Anon login and bounce FTP checks are perform by default by nmap with -sC option or:
nmap --script ftp-* -p21<ip>
Browser connection
You can connect to a FTP server using a browser (like Firefox) using a URL like:
ftp://anonymous:anonymous@10.10.10.98
Note that if a web application is sending data controlled by a user directly to a FTP server you can send double URL encode %0d%0a (in double URL encode this is %250d%250a) bytes and make the FTP server perform arbitrary actions. One of this possible arbitrary actions is to download content from a users controlled server, perform port scanning or try to talk to other plain-text based services (like http).
Download all files from FTP
wget-m ftp://anonymous:anonymous@10.10.10.98 #Donwload all
wget-m --no-passive ftp://anonymous:anonymous@10.10.10.98 #Download all
Some FTP commands
FTPBounce attack
Some FTP servers allow the command PORT. This command can be used to indicate to the server that you wants to connect to other FTP server at some port. Then, you can use this to scan which ports of a host are open through a FTP server.
You could also abuse this behaviour to make a FTP server interact with other protocols. You could upload a file containing an HTTP request and make the vulnerable FTP server send it to an arbitrary HTTP server (maybe to add a new admin user?) or even upload a FTP request and make the vulnerable FTP server download a file for a different FTP server. The theory is easy:
Its highly probably that this will throw an error likeSocket not writablebecause the connection doesn't last enough to send the data with RETR. Suggestions to try to avoid that are:
FileZilla usually binds to local an Administrative service for the FileZilla-Server (port 14147). If you can create a tunnel from your machine to access this port, you can connect to it using a blank password and create a new user for the FTP service.
Config files
ftpusers
ftp.conf
proftpd.conf
vsftpd.conf
Post-Exploitation
The default configuration of vsFTPd can be found in /etc/vsftpd.conf. In here, you could find some dangerous settings:
SBOM 은 SOFTWARE BILL OF MATERIALS 의 약자로 소프트웨어의 구성 요소를 나타내는 메타데이터를 의미하는데 이를 보다 쉽게 설명하자면 우리가 흔히 볼 수 있는 다음과 같은 제품의 성분표기를 떠올리면 됩니다.
성분표기를 통해서 알러지가 있는 사람은 해당 식품을 피하기도 하고, 공급자는 제품의 우수성을 홍보하기도 하고, 크게 성분에 신경쓰지 않고 그냥 사용하는 사용자도 있을 수 있죠.
이와 유사하게, SBOM은 공급되는 소프트웨어의 구성 목록을 잘 표시해서 공급자와 사용자가 이를 기반으로 의사결정에 활용할 수 있는 환경을 조성하는 것을 목표로 하고 있습니다.
NTIA 에서 발표한 SBOM의 필수 구성요소는 다음과 같이 구성되어 있습니다.
Supplier name
Component name
Version of the component
Cryptograph hash of the component
Any other unique identifier
Dependency relationship
Author of the SBOM data
이를 기반으로 작성한다면 다음과 같은 개념도로 표시할 수 있습니다.
National Telecommunications and Information Administration (NTIA) 에서는 오픈소스 소프트웨어나 상용 소프트웨어로 구분하지 않고 모든 공급되는 소프트웨어를 대상으로 광범위하게 적용할 수 있는 SBOM 적용을 위해 산업계의 여러 기업과 커뮤니티에 의견을 청취하고 이를 토대로 SBOM의 이해를 돕는 자료와 적용방법에 대하여 다양한 문서를 배포하고 있으니 아래 문서들을 참고하시기 바랍니다.
SBOM이 소프트웨어 보안의 모든 문제를 해결할 수는 없지만 보다 안전한 소프트웨어 사용에 필요한 기본을 제공하는 것은 분명히 필요한 일이며, 다양한 산업계의 의견을 토대로 만들어진 SBOM을 기반으로 소프트웨어 공급망의 투명성을 강화할 수 있는 미국의 이번 정책은 향후 IT 산업과 디지털 인프라의 소프트웨어 관리에 있어서 매우 중요하다고 생각됩니다.
Years ago, a team of researchers at SUTD (Asset-Group) discovered and disclosed the family of vulnerabilities in the classic Bluetooth link manager layer. They've released a paper and POC named "Braktooth: Causing Havoc on Bluetooth link manager" The paper is very detailed and enjoyable to read. I highly recommend it to anyone into Bluetooth security. The Braktooth is a codename for 16 classic Bluetooth vulnerabilities. It will cause affect BT devices continuously crash or deadlock. Furthermore, at least in one case, attackers can remotely execute arbitrary code and erase all the data on the targeted devices. These bugs are present in various BT Chipsets across many manufacturers such as Intel, Qualcomm, TI, Infineon, etc.
Since my main interest focused on vehicle security, after reading through the Braktooth paper, one thing immediately got my attention. They mentioned in the paper, Braktooth not only affects laptops, and smartphones but also Infotainment units in Automobiles, even the audio system in airplanes is affected. For IVIs, they listed the Volvo FH as an example in the paper. This got me wondering if any other popular cars out there are also affected by Braktooth.
FIRST-BLOOD
Before we jump on the cars, we need to get familiar with Braktooth. The actual environment is quite simple to set it up. In the paper, they mentioned some Chipset from Mediatek that are affected. My laptop Lenovo L14 happened to use the Ralink chipset for Bluetooth communication. Since Ralink is part of the Mediatek group, which make it is the perfect target for the test run.
Because there are 16 POCs from the Braktooth vulnerabilities, we've to go through all of them. And we found one of the vulnerabilities called Invalid-Timing-Accuracy almost always work. The vulnerable chipsets do not properly handle the reception of a malformed LMP timing accuracy response followed by multiple re-connections to the target link slave.
This allows attackers to exhaust device BT resources. The attacker can trigger a crash or disturb other BT devices connected to the target chipset. The best part is attacker only needs to know the BDAddress of the target device. No authentication is required to launch the attack. As the video below demonstrated, the Bluetooth connection between the laptop and speaker stop functioning and eventually disconnected the connection.
INVESTIGATION
People always ask us how can Star-V Lab access so many cars. And this project is a perfect chance to show how we achieved it. The easiest place to start would be for the Car components to sit on the test bench table. For example, we happened to have a 2nd hand Nissan IVI in the lab. As we can see, after we fired the Invalid-Timing-Accuracy POC, the Nissan IVI kind of frozen, and it won't detect any Bluetooth devices nearby anymore.
The 2nd place to look for potential targets is the company car parking lot. If we ask nicely, most of the staff even the company CEO are interested to see if their car can hacked ;) At that time, we got 2 Tesla cars and 1 Changan Uni-T accessible for testing. For Tesla Model 3 and Model X, only the Invalid-Setup-Complete POC worked. All other POCs failed.
But for Changan Uni-T almost all the vulns works. Only 6 of the POC has no impaction. As the video shows, Braktooth disconnected the connection. Interestingly the Bluetooth logo on the IVI screen still shows everything is fine, but in fact, the connection has been disconnected.
If we got enough budget we can rent some cars for testing. But what if our budget is short and we need to test the latest modern cars? An advantage of living in a big city is we are surrounded by Car dealer shops. And these are perfect spots for us.
This time we found 4 cars affected by Braktooth. The first one is NIO ET5, which is a Chinese brand and quite popular in China.
For NIO it will disconnect the Bluetooth connection straight away.
Then we went to the Volkswagen to test ID4X. Compare to other Android-based IVI, ID4X seems a bit hard to use.
Again once we fired the attack, the Bluetooth connection disconnected.
Finally, we tested a new smart car player in the Chinese market called ARCFOX. As the video shows the music start been funny after we fired the attack.
One thing special regarding this brand is one of the car models using the Huawei HarmonyOS as IVI's system.
However, when coming to low-level Bluetooth attack, Huawei HarmonyOS makes no difference.
Another nice spot for testing is the Car exhibition. The good thing about the exhibition is we may able to test some fancy sports cars, which normally we won't be able to touch.
Here we've tested the Neta V and Leapmotor C01 cars.
As we can see both of them experienced the disturb first then the connection disconnected completely.
FINAL-FHOUGHT
As whitehat security researchers, we like to follow the responsible disclosure procedure. Unfortunately unlike the Internet companies, most car companies still live in a stone age. They neither don't have a bounty program nor contact info for reporting bugs. Therefore, we filed a report to their customer service and hope someone can see it. But we like to give a thumbup to the Tesla and NIO. These two companies have set up bug bounty programs and given a very quick response to our bug report. However, Nio replied that this bug has out of their scope.
And Tesla thinks this is not a security issue, since the braktooth was only able to cause the Tesla Bluetooth audio jitters. We kind of agreed on this point, so let's continue our journey and digging deeper. Spoiler alert, we did find other issues on some of those IVIs above. And at least caused one of the fancy car's IVI to go black screen. Stay tuned for our future report ;)
Once the device is on and plugged in, it wakes up the CAN network by sending a frame—similar to if you were to pull on a door handle, approach with a passive entry key, or hit a button on your fob. It then listens for a specific CAN message to begin its attack. The device then emulates a hardware error which tricks other ECUs on the CAN network to stop sending messages so that the attacking device has priority to send its spoofed messages to CAN devices.
The pause of valid messages is when the device is able to go into attack mode. It then sends the spoofed "valid key present" messages to the gateway which makes the car think that an actual valid key is being used to control the vehicle. Next, the attacker simply presses the speaker's "play" button, and the car's doors are unlocked.
Given that the manufacturer of these CAN injection devices claims that the devices are so effective against a myriad of makes and models, it would seem that this could be an industry-wide problem that may take some brainstorming to fix.
The good news is that this type of attack can be thwarted. While there are quick-and-dirty methods that could potentially be re-defeated in the long run, an automaker looking to prevent this type of attack by encrypting its CAN Bus network. According to Tindell, Canis is working on a similar project to retrofit U.S. military vehicles with a similar encryption scheme, similar to what he suggests as the fix for commercial vehicles experiencing this issue.
오늘은 안전한 시스템 & 소프트웨어 개발의 기반이 되는 시스템 & 소프트웨어 품질 관리 (Quality Management) 측면의 프로세스 표준인 ASPICE 에 대해 설명하도록 하겠습니다.
Overview
ASPICE 는 Automotive SPICE (Software Process Improvement Capability dEtermination)의 약어로 유럽 주요 OEM이 자동차용 S/W 를 개발하는 부품 업체의개발프로세스의 역량을 평가하기 위한 목적으로 만든 산업계 통용 표준입니다.
ASPICE 의 내용은프로세스 능력의 평가를 위한 프로세스 측정 프레임워크 표준인 ISO/IEC 33020 과프로세스 수행능력 평가 프레임워크 표준인 ISO/IEC 15504 를 기반으로 작성 되었습니다.
ISO 15504 SPICE - wiki & ISO/IEC 33020
ASPICE 는 부품을 공급하는 공급업체의 개발 프로세스의 역량을 평가하고, 결과를 공식적으로 등급화하여 공급업체의 품질 능력 향상을 목적으로 활용이 되고 있습니다
ASPICE 는 크게 3가지로 구성이 되어 있는데, 먼저 차량 SW 개발 시 참조하여 수행할 수 있도록 제공되는 프로세스 참조 모델 (PRM, Process Reference Model) 과 공급업체의 능력을 평가하는 프로세스 평가 모델 (PAM, Process Assessment Model) 그리고 프로세스별 역량을 평가할 수 있는 측정 프레임워크 (MF, Measurement Framework (ISO/IEC 33020)) 로 구성되어 있습니다.
전체 개발 프로세스의 역량 수준은측정 프레임워크에 따라 6개의 역량 수준이 존재하며 각 수준 별 내용은 다음과 같습니다.
역량 수준
설명
프로세스 속성
수준 0 : 불완전한 프로세스 (Incomplete)
프로세스가 이행되지 않거나 프로세스 목적을 달성하지 못함
-
수준 1 : 수행된 프로세스 (Performed)
프로세스가 수행되어 프로세스 목적을 달성
PA 1.1 프로세스 수행 (Process performance)
수준 2 : 관리된 프로세스 (Managed)
프로세스가 계획, 감시, 조정되며 프로세스에 의해 생성된 작업 산출물이 적절하게 작성되고, 통제되고, 유지됨
PA2.1 수행 관리 (Performance management) PA 2.2 작업 산출물 관리 (Work product management)
수준 3 : 정립된 프로세스 (Established)
수준 2를 달성할 수 있는 정의된 프로세스가 있으며, 평가 받는 프로세스가 해당 정의된 프로세스로 수행됨
PA3.1 프로세스 정의 (Process definition) PA3.2 프로세스 전개 (Process deployment)
수준 4 : 예측 가능한 프로세스 (Predictable)
정립된 프로세스가 프로세스 성과를 달성하기 위해 정의된 한계 내에서 예측적으로 운영됨 즉, 프로세스 내의 여러 요소들을 정량적으로 측정 및 분석하여 이상 원인을 식별하여 해당 이상 원인을 해결
PA4.1 정량적 분석 ((Process) Quantitative analysis) PA4.2 정량적 통제 ((Process) Quantitative control
수준 5 : 혁신 프로세스 (Innovating)
예측 가능한 프로세스가 조직차원의 정략적 피드백을 통해 전사 프로세스를 지속적으로 개선하고 실제 프로젝트를 개선된 프로젝트로 수행
PA5.1 프로세스 혁신 (Process innovation) PA5.2 프로세스 혁신 이행 (Process innovation implementation)
위에서 정리한 개발 프로세스의 역량 수준은 ASPICE 의 3가지 구성 요소인 PRM, PAM, MF 를 이용하여 결정되며 이에 대한 설명은 PRM, PAM, MF 에 대해 설명을 한 후 마지막에 설명하도록 하겠습니다. (아래 그림은 역량 수준을 결정하기 위한 PRM, PAM, MF 을 이용한 2차원 프레임워크입니다. 자세한 내용은 아래 설명하겠습니다.)
프로세스 참조 모델 (PRM, Process Reference Model)
ASPICE 의 프로세스 참조 모델은 위의 그림과 같이 32개의 프로세스의 집합을 제공합니다.
PRM에서 프로세스는 프로세스 카테고리 별로 그룹화되고 카테고리 내에서의 프로세스는 처리하는 활동 유형에 따라 프로세스 그룹으로 그룹화 됩니다.
프로세스 카테고리 분류는 아래과 같습니다.
Primary Life Cycle Processes : 제품 / 시스템 개발에 필수적인 프로세스의 그룹
Organizational Life Cycle Processes : 조직 차원에서 관리 및 수행이 필요한 프로세스 그룹
Supporting Life Cycle Processes : 다른 그룹이 원활이 수행 되도록 지원하는 프로세스 그룹
카테고리 별 프로세스 그룹은 아래과 같습니다.
Process Categories
Process Group
Primary Life Cycle Processes
Acquisition process group
Supply process group
System engineering process group
Software engineering process group
Organizational Life Cycle Processes
Management process group
Process improvement process group
Reuse process group
Supporting Life Cycle Processes
Support process group
PRM 각각의 프로세스는 프로세스의 명칭, 프로세스의 목표 (Purpose statement), 목표와 관련된 결과 리스트 (Process outcomes) 로 구성되어 있습니다.
ASPICE 에서 제공하는 PRM 의 템플릿과 작성된 PRM 은 아래와 같습니다.
VDA Scope
앞서 말씀드린바와 같이 ASPICE 는 총 32개의 프로세스로 구성이 되어 있는데, 이 중 필수/기본 범위로 VDA 에서 정한 16개의 프로세스를 VDA Scope 이라 하며, VDA scope (구, HIS Scope) 은 아래 그림의 빨간 테두리의 프로세스에 해당합니다.
ASPICE PRM - VDA Scope
Process Group
Process
Acquisition process group
ACQ.4 Supplier Monitoring
Supply process group
N/A
System engineering process group
SYS.2 System Requirement Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Test
SYS.5 System Qualification Test
Software engineering process group
SWE.1 Software Requirement Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Integration and Integration Test
SWE.6 Software Qualification Test
Management process group
MAN.3 Project Management
Process improvement process group
N/A
Reuse process group
N/A
Support process group
SUP.1 Quality Assurance
SUP.8 Configuration Management
SUP.9 Problem Resolution Management
SUP.10 Change Request Management
프로세스 평가 모델 (PAM, Process Assessment Model)
프로세스 평가 모델 (PAM, Process Assement Model) 은 프로세스 참조 모델(PRM, Process Reference Model) 의 프로세스 성과 (process outcome) 와 측정 프레임워크 (MF, Measurement Framework) 의 속성 성과 (process attribute) 가 실제 수행된 (instance 화 된) 프로세스에 존재하는지를 식벽하기 위한 지표를 제공합니다.
이 지표는 평가자가 실제 수행된 프로세스에 대해 역량 수준을 평가할 때 사용 됩니다.
프로세스 평가 모델에서 사용되는 지표는 아래 2가지가 있습니다.
프로세스 수행 지표 (process performance indicator)
역량 수준 1에만 적용 가능
PRM 의 프로세스 성과 (process outcome) 의 수행 정도를 확인 할 수 있는 지표를 제공
기본 사례 (BP, Base Practice, 수행 지향적 지표), 작업 산출물 (WP, Work Product, 결과 지향적 지표) 두 가지 유형으로 구분
작업 산출물의 경우, 작업 산출물 특성 (WPC, Word Procuct Caracteristic) 이 존재
프로세스 능력 지표 (process capability indicator)
역량 수준 2~5 에 적용
MF 의 프로세스 속성 성취 (process attributea acheivement) 의 달성 정도를 확인할 수 있는 지표를 제공
일반 사례 (GP, Generic Practice, 수행 지향적 지표), 일반 자원 (GR, Generic Resource, 결과 지향적 지표)
위의 프로세스 평가 모델에서 제공하는 지표와 프로세스의 역량 (CL, Capability Level) 간의 관계는 아래 그림과 같습니다.
프로세스 수행 지표 정리
앞서 정리한 대로, 프로세스 수행 지표 (process performance indicator) 는 기본 사례 (BP) 와 작업 산출물 (WP) 두 가지 유형이 존재합니다.
기본 사례, 작업 산출물, 작업 산출물 특성 및 프로세스 성과간의 관계
두 지표는 각 프로세스마다 정의되며 두 지표 모두 하나 이상의 프로세스 성과 (process outcome) 와 관련이 있으며 ASPICE 에서는 각 기본 사례 (BP), 작업 산출물 (WP) 마다 관련된 프로세스 성과 (process outcome) 을 정리합니다. (아래 예제 참조)
예제) SYS.2 System Requirement Analysis
예제. SYS.2 System Requirement Analysis 의 Process outcomes
예제. SYS.2 System Requirement Analysis 의 Base practices
예제. SYS.2 System Requirement Analysis 의 Work products
추가로, 작업 산출물 (WP)의 경우, 각 작업 산출물 (WP) 마다 작업 산출물 특성 (WPC) 이 존재하며 위의 예제에 있는 Review record 작업 산출물 (WP) 에 대한 작업 산출물 특성 (WPC) 은 아래와 같습니다.
위의 작업 산출물 (WP) Review record 에 대한 작업 산출물 특성 (WPC) 을 보면 해당 작업 산출물의 내용, 산출물의 구조, 형식 등이 정리된 것을 볼 수 있습니다.
이는 프로세스를 평가하는 심사자가 작업 산출물에 대해 평가할 때의 지표로 사용될 수도 있으며, 프로세스를 설계 및 구축하는 프로세스 조직에서 산출물 템플릿 문서 등을 만들 때 사용할 수도 있습니다.
ASPICE 에서는 위에서 정리한 기본 사례 (BP), 작업 산출물 (WP), 작업 산출물 특성 (WPC) 에 대해 엄격한 필수 사항도 아니며 조직을 위한 준수수항도 아니라고 설명하고 있기에, 실제 업무를 수행하는 것에 대해 생각을 해보면 위의 작업 산출물 특성 (WPC) 에 정리된 내용을 조직에 맞춰 선별하여 작업 산출물 (WP) 을 작성하는 것이 효율적일 수 있겠다 생각합니다.
프로세스 능력 지표 정리
앞서 정리한 대로, 프로세스 역량 지표 (process capability indicator) 는 일반 사례 (GP) 와 일반 자원 (GR) 두 가지 유형이 존재합니다.
일반 사례, 일반 자원, 프로세스 속성 성취 간에 관계
두 지표는 각 프로세스 속성 (process attribute) 마다 정의되며 모두 하나 이상의 프로세스 속성 성취 (process attribute achievement) 와 관련이 있으며 ASPICE 에서는 각 일반 사례 (GP), 일반자원 (GR) 마다 관련된 프로세스 속성 성취 (process attribute achievement) 을 정리합니다. (아래 예제 참조)
예제) PA 2.1 Performance management process attribute
예제. PA 2.1 Performance management process attribute 의 achievement
예제. PA 2.1 Performance management process attribute 의 Generic practices
예제. PA 2.1 Performance management process attribute 의 Generic resources
위의 예제의 상세 내용을 보면 알 수 있듯이, 프로세스 역량 지표 (process capability indicator) 의 경우, 프로세스 수행 지표 (process performance indicator) 와는 달리 전체 프로세스에 적용 할 수 있는 일반적인 형태로 작성되어 있습니다.
즉, 프로세스 역량 지표 (process capability indicator) 는 프로세스 참조 모델 (PRM) 에 있는 어떤 프로세스에도 적용되는 지표입니다.
프로세스 역량 수준 1은 프로세스 수행 지표 (process performance indicator) 에 의해서만 특정되지만, 측정 프레임워크 (Measurment Framework) 는 각 역량 수준 마다 프로세스 속성 (process attribute) 을 정의할 것을 요구합니다. 이에, ASPICE 에서는 프로세스 역량 수준 1에 대한 프로세스 속성을 프로세스 수행 지표를 달성 하는 형태로 아래와 같이 정의합니다.
QNX는 1982년부터 원자력 발전소, 수술용 로봇, 산업용 로봇 및 차량과 같이 안정성 및 보안을 요구하는 임베디드 시스템을 위한 소프트웨어를 제공하고 있습니다. QNX의 소프트웨어는 1억 2천만 대 이상의 자동차에 배포되었으며 메르세데스, 아우디, BMW, 현대, KIA 등 45개 이상의 다양한 자동차 제조업체 제품에 적용되었습니다. TÜV Rheinland로부터 ISO 26262 ASIL D등급과 IEC61508 SIL3 등급의 인증을 획득한 OS를 보유하고 있어 고객은 개발할 시스템의 안전 인증을 획득하고 유지하는 비용을 최소화 할 수 있습니다.